On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: > > 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
I see. What does "current" has to do with it then ? in the current
state of affairs, nothing prevent the maintainer to only build the
package for $(pyversions -d) only, which would be:
(1) binNMUable
(2) only built for the current python version as per spec of what you
want to achieve.
I think I don't say anything foolish here, and that current was not a
requirement.
Though, I know what you will argue next, it's that you need (as a RM)
to be able to compute the list of packages needing to be queued for
binNMU. I've not evaluated yet if current helps here or not (I don't
think so, but I've nothing to backup that assertion yet, so I wont say
anything until I've a good and minimal solution to propose).
> as a result of Josselin's process hijacking. Oh well.
Bleh, I think we can avoid that part :) I don't want to point fingers,
but to find solutions. Really.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpXiV1CCpJFv.pgp
Description: PGP signature
