On Wed, Mar 21, 2007 at 02:44:29PM -0700, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote: > > > I think it's time to update the python policy with the progress that has > > been made in how we build python packages. The proposed diff is > > attached. In summary it includes: > > * the deprecation of the "current" keyword; > > So with current deprecated, what is the solution for a package which wants > to build a single binary extension for the current python version in a > package named python-foo, with no support for other versions of python > returned by pyversions -s?
I must say I quite agree with Josselin here. What would be the purpose of a package like this ? Either we comply with the idea behind the policy, meaning that a package is built for as many supported python version we can, either we don't. If we don't, I don't see the purpose of the policy alltogether. If we do, then current is quite broken IMHO. I mean, we have basically 3 types of packages (there is more, but for what I will try to expose, we can fold things onto those three). * packages written in pure python: those enter in the scope of the policy as soon as they support (at least) the default python version. In that case, well, there is nothing special to do, it spoils nothing (neither build time nor space) to support every python version available. * packages with private binary modules: those (with or without "current") can only be built for one version of python at a time. For them current is meaningless. In fact it's even confusing, because when you look at a package that was built with a pythonX.Y as default, current meant X.Y at that time. If you look it after having switched to a pythonX'.Y' the "current" you see has another meaning (and yes pycentral uses it in XB-P-V, and IMHO it's a bug). * packages with binary public modules. Those are the one that indeed may spoil a bit of resources (space on the user hard drive, and time as we basically build the package twice). Though, if we have concerns about speed or time for _public_ modules (meaning the very modules that are meant to be used by the programmer right?) we fail completely to follow the spirit of the "new" (that is not so new right now ;p) policy. So here current seems if not broken, nor useless, at least against the idea of the policy. Is there anything that I miss with those explanations ? -- ·O· Pierre Habouzit ··O [EMAIL PROTECTED] OOO http://www.madism.org
pgpxYpbSB6Wlh.pgp
Description: PGP signature