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]