> > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
