Re: python packaging infrastructure
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> > sorry, what is complicated about the solution?
> >
> > please read again, these benefits aren't just aesthetic:
> >
> > - working on metadata without having all packages available (which
> > ones?) is not just aesthetic.
>
> What exactly do you want to do with such metadata?
the question is wrong, you don't deny the need for metadata. it's a
question where you want to expose it.
> > - beeing able to support more python versions in a separate archive
> > is not just aesthetic (although not needed in the distribution,
> > but often requested on python-dvel).
>
> More python versions? You mean, a separate archive with a different
> python version as the default?
developers did express the need to test their application with
different python versions. A separate archive could be used for such a
setup. The default python version doesn't matter, as we do want to
move away from that dependency.
> > > Furthermore, if you want to see this implemented, you'll have to find
> > > someone else to write the necessary changes to dh_python. I will not
> > > write nor maintain any code that parses the control file in dh_python.
> > > This script is already one of the most complex ones in debhelper, and
> > > everything you have proposed so far is going to make it look like hell.
> >
> > It strikes me that you prefer an "easy-to-implement" over an
> > "easy-to-use" solution. Do you give the same commitment to support the
> > python-support package?
>
> First, this isn't a question of ease-of-use, but of added functionality.
> Both solutions are equally easy to use, it's just one being more
> complicated for more functionality. Besides that, I prefer an
> easy-to-implement solution for anything that touches dh_python. This
> script is written in perl, a language that few people on this list seem
> to use, and it is already way too complicated for a helper script. If
> you want the metadata to be handled by dpkg, the functionality should be
> added to dpkg itself.
>
> Of course this doesn't apply to python-support itself, which was written
> from scratch in python.
no, a solution just handling modules isn't "equally easy to use".
> > no, it's not urgent, it has to be done for the release. I don't see
> > anything helpful in uploading an incomplete solution without a
> > discussion.
>
> Looking at the mailing list archives, some people have tried to initiate
> discussions about making python in Debian evolve in the recent months,
> but it doesn't look like there has been much interest.
please see debian-release, I always stated that I do not want to start
the python transition before the C++ stuff was finished.
> > again, I disagree on this procedure. Surely the 2.4 transition should
> > happen soon, but I disagree on your "urgent" argument. I don't know
> > how to work the best way with you on this topic, your only argument
> > beeing "too complicated to be implemented within two days".
>
> You can read this as "show me the code".
sorry, I don't understand what you mean.
> About the "urgent" argument, looking at the bunch of transitions that
> have happened and still have to happen in testing, we should avoid to
> make the python 2.4 transition look like the previous ones, having to
> migrate all python packages to testing at the same time. The number of
> python packages has been increasing too much for making this possible in
> a reasonable amount of time.
correct, but making it easier for extensions and applications using
private modules as well. when will python-support be able to support
these?
> > > And while I'm digressing, changing the python policy so that only one
> > > python version at a time is supported would be much simpler. Simpler for
> > > you as python maintainer, simpler for people like me developing
> > > intermediate layers, and simpler for package maintainers. I happen to
> > > like simple things.
> >
> > as simple as "remove any software which doesn't work with this one
> > version"? Taking up your shlibs example, why not do the same with
> > library packages? There is a real reason we do have developed
> > procedures for transitions ...
>
> There are not many libraries that are present in Debian with several
> versions at the same time, and I don't think they are good examples of
> sane practise we should follow.
I still see python2.5 as the default version for etch as a possible
goal, with some applications not yet ready for this one using an older
version. Any packaging infrastructure which will allow testing this
outside the archive first will help. And this includes again
extensions and applications using private modules.
Matthias
Reply to: