Re: python-central vs python-support
On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> policy is. So here's *my* attempt at summarizing the BoF, based on your
> first mail and responses, and independent of the tools used:
>
> 1) Public modules and extensions should support all available Python
> versions, using a single binary package.
>
> 2) A new control field, XC-Python-Version will be used to determine what
> versions of Python a module supports.
>
> 3) The tight upper bound on module dependencies will be removed,
> provided the module actually works on future versions of Python. The
> upper bound on extension dependencies will not, because then they
> wouldn't work.
>
> 4) python2.x-* virtual packages are to be used only when necessary, but
> packages can provide them regardless.
>
> 5) Private modules and applications should use some way to support more
> than one Python version, if possible.
>
> Is this accurate? 1), 3), and 4) contridict your original email, but
> match what you told me this time.
Yes, this is a good summary IMO, however I don't remember if we discussed
point 5.
> 4) I am still unsure of, because Steve and Matthias gave different
> answers, and your answer is confusing -- if they're desirable, let's
> make them required; if not, let's not pollute the (virtual) package
> namespace unless we need them for a specific reason.
The reason exists, those virtual packages are needed to properly express
dependencies of an application which uses a non-current python version.
However very few apps are in that case so we said that we might only add
the provides on the few modules which are really concerned.
> 2) is suspect. It's not required for multiversion support *in policy*.
> The working python-support implementation in unstable, while still
> lacking such fields, proves that. I feel it's much more of an
> implementation issue than a policy one, and so if we don't use
> python-central (which I gather is the impetus for it), we shouldn't
> bother with the control field either.
Right. However Steve agreed that having this information in Packages.gz
file would ease extraction of lists of packages which have to be bin-NMUed
for a python transition.
I had the same reservation than you on this issue. But on the other hand it
doesn't hurt much to require that field if we have the required support in
dh_python.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: