[Stefano Rivera, 2011-03-24]
Hi, since #604167 was resolved, dh_python2 changed behaviour in
python-defaults 2.6.6-12, and doesn't use ${python:Breaks} any more.
Thus all packages installing public modules with dh_python2 will trigger
old-versioned-python-dependency.
I suggest either
Hi Scott (2011.03.19_05:52:49_+0200)
What else needs doing?
I suggest making it clearer in the policy that byte-compilation etc.
are best taken care of by helpers. The policy *is* probably the first
place that someone looking to create a Python module/app package will
look.
There are a few
On Thursday, March 24, 2011 09:35:21 am Stefano Rivera wrote:
I see we still suggest ${python:Provides}. I was encouraged in
#debian-python to never use these unless there's an existing
dependency on a versioned package name.
There are no real packages using a name like python2.X-modulename.
Hi Scott (2011.03.24_15:45:36_+0200)
I think once we get to pyhton2.7 as the only supported python, it
won't matter.
As long as we handle rebuilds after every transition, it already
shouldn't matter (in Python 2 and 3). With dh_python2 we have the same
rebuild requirements, but don't suggest
Most of you probably figured this out already from the cc: of 619487 to
debian-python, but just in case ...
dh_python2 dropped ${python:Breaks} - This means you should remove Breaks:
${python:Breaks} from packages as you update them. In the mean time, it's
presence is harmless so there's no
A couple of days ago I updated python-defaults and today (it's still Thursday
in my mind because I haven't slept yet) I updated python3-defaults. Unstable
now how the latest dh_python2/dh_python3 and pycompile changes.
The only difference between Unstable and Experimental is which
6 matches
Mail list logo
