On Sun, Feb 18, 2007 at 03:47:23PM -0800, Steve Langasek wrote:
> On Sat, Feb 17, 2007 at 10:26:23AM -0500, A. Christine Spang wrote:
>
> > I've just recently had my sponsor upload gquilt 0.17-3 to unstable. I'm
> > requesting that it be granted a freeze exception for fixing RC bug
> > #411198 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411198).
>
> - Why is the depends: on python (>= 2.4), (<= 2.5) hardcoded now, instead of
> being autopopulated from ${python:Depends} by way of XS-Python-Version:
> current?
How exactly does XS-Python-Version: current work? It doesn't seem to add
the right dependencies under Depends: when I try building using
${python:Depends}. I get a Depends: line that looks like this:
Depends: python-central (>= 0.5.8), python-gtk2 (>= 2.4), quilt
Which is why I added the hard dependency in the first place.
The only other field in the generated binary control file that I see that's
relevant is Python-Version: current, but I don't know if or how that has
an effect on dependencies.
> - The bounds of the range are wrong -- python (<= 2.5) is satisfied by a
> version number of exactly 2.5, but that would be incompatible at the
> bytecode level...
Huh, that's right. Note that this is stated incorrectly in the
python policy manual:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs
> - It would be nice if there were support for automatically recompiling
> bytecode for private modules when python is upgraded; but I guess that
> part of the proposed python policy didn't get spec'ed out in time? Well,
> I guess it can be done with an rtupdate script, but that it's by no means
> required under current policy, ahwell.
While I agree that this would be nice, I'm told that there is no helper
for this yet, and I don't think it's really worth it to implement
something like that for this package in particular before etch.
Regards,
Christine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
