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