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 madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpQxFGDf06wg.pgp
Description: PGP signature