Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
> 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.
No. That may have been the idea behind *Josselin's* policy, but that was
never "the" idea behind the policy that was being proposed and discussed
early last year on this list.
> If we don't, I don't see the purpose of the policy alltogether.
Allowing transitions between default versions of python without package
renames, bypassing NEW, allowing binNMUable transitions, and generally
simplifying the python upgrade path for users across releases.
Supporting multiple binary extensions in a single python-foo package is a
tool that *facilitates* that goal, but it was *never* supposed to be
mandatory. There are extensions with no/few reverse-dependencies and a
small install base, such that supporting multiple versions of python is
useless archive bloat.
Evidently everyone has lost sight of this as a result of Josselin's process
hijacking. Oh well.
> * 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.
No, it's your ideas of what the policy should be that are broken.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: