On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote: > 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. > 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. In the original proposal, 'current' was the flag to tell the packaging tools that pyversions -d *should* be used. There is of course nothing that stops a maintainer from invoking pyversions -d manually; the question is, how will doing so fit into the python policy, will there be support for automating this in the helper tools, and will packages that do this (and are therefore binNMUable for python transitions) be automatically detectable from the Sources and/or Packages files? > 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. Exactly. :) > 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). Ok, I look forward to hearing this proposal. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
