Re: python-central vs python-support
> > s/available/supported/. we will try to keep the number of supported
> > python versions/implementations minimal.
>
> Is there difference between available and supported versions ? What use
> for an official python package if it is not supported ?
assume we want to add a python2.5 package. It's nice to have, but
extensions will need an update, or they will FTBFS. At this point I
would rather not see python2.5 as supported.
> > Plus XS-Python-Version, from which XC-Python-Version is generated from.
>
> Why is this necessary ? You said you plan on having a dh_pycentral
> script, why can't this one do the job automagically ? Why having the XC-
> remain in package information then ?
The 'Provides: python2.3-foo, python2.4-foo' is missing for all
packages with private modules and scripts (without shared modules).
For that case we do need XB-Python-Version. If we do want to drop the
Provides for packages where they are not needed, we need it for shared
modules as well.
> >> 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.
>
> I don't see any reason to keep this boundary, really, as you plan to use
> binNMUs on transitions. Either the extension does not work on a newly
> uploaded python version after being binNMU-ed, then this is a bug (not
> grave), or you use a boundary for an extension which would have worked
> perfectly and this is a bug too. As this is of the same severity, i
> would rather have to consider a bug for an upstream lack of support for
> a new version rather than for my extensions because of fear.
this kind of dependency doesn't hurt, if the extensions are available
for the two versions used in the transition.
> >> 4) python2.x-* virtual packages are to be used only when necessary, but
> >> packages can provide them regardless.
> >
> > you don't know in advance, if they are necessary. Not a problem, if
> > they are generated.
>
> Yes i agree. But what a pollution. Now when Ruby and other langages would
> do the same, i'd like to know how long apt would be...
does apt takes a performance hit with unused provides? Well, really,
just stop adding new packages to unstable has the same effect ;)
> >> 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.
> >
> > we agreed to use this information so that you can decide on package
> > rebuilds based on the Sources and Packages files. See my slides from
> > Debconf.
>
> Where are those slides ?
http://people.debian.org/~doko/pycentral/
> Should we be aware where your things are stored ?
yes, see http://lists.debian.org/debian-python/2006/05/msg00062.html
> Don't you think this new field and Provides are redondant, and that you
> could decide which rebuilds are necessary from it ?
no, not for packages with private extensions.
Matthias
Reply to: