On Thu, Mar 22, 2007 at 12:36:07AM +0100, Pierre Habouzit wrote:
> > * set XB-Python-Version to "current, >2.5" # here "current" can't be
> > deprecated,
> > but this field should be filled automatically (think ${python:Versions})
> > so maintainer doesn't have to know about "current"
> current, > 2.5 has no sense at all, at least today, as current is
> (today) meaning: please build that for python2.4
It would mean that such a package is not buildable today in unstable. Why
is that not a useful declaration to have? Just because a build-dependency
isn't satisfiable doesn't make the build-dep itself useless. (E.g., for an
example strictly within Debian, consider a package uploaded to lenny that
had this declaration as a means of preventing broken backports.)
> But IMHO the new policy doesn't help you if your package doesn't
> support the current default python. I mean, there is obviously tricks in
> the debian/rules that are possible to render the package binNMUable, but
> I don't think the dh_py* tools can help here. But I may be mistaken.
I believe that's correct.
> > case 3:
> > * build for all supported python versions (that are >=2.3)
> > * set XB-Python-Version to ">2.3" (or "2.3-")
> > * no binNMU needed, just recompile after `pyversions -s` will change
> no recompilation is needed in that case, even if pyversions -s
> changes.
As you allude later, ideally you would have binNMUs in response to the
pyversions -s change, so that the package is updated for additions/deletions
to the supported list. The binNMU is not *required*, true, but doing such
binNMUS may be a factor in how smooth the upgrade path is between stable
releases.
--
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]
