Re: python packaging infrastructure
Le lundi 16 janvier 2006 à 12:40 +0100, Matthias Klose a écrit :
> > 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.
If you want the transition to go smoothly, the move to a packaging
system where packages don't all depend strictly on a python version has
to be done before the transition.
> > 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?
Python-support already handles private modules. As for extensions, I
don't think we should change the current packaging practise. Packaging
them is already complicated enough as it is.
> > 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.
I am not arguing against keeping several versions of the interpreter
available. Developers need to test their applications with different
versions. Now, if we have:
- python-only modules and private modules handled by python-support;
- several python2.X versions available in the archive;
- for extensions, several python2.X-foo and a default python-foo as we
do today;
with all of this, testing each application against a new python version
outside the archive becomes possible. Not trivial, but possible.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Reply to: