Coin, Matthias Klose <[EMAIL PROTECTED]> writes:
> 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 ? > 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 ? >> 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. >> 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... >> 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 ? Should we be aware where your things are stored ? Don't you think this new field and Provides are redondant, and that you could decide which rebuilds are necessary from it ? -- Marc Dequènes (Duck)
pgpaTiIcpDS0S.pgp
Description: PGP signature
