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 Python/Pyth
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 ne
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 $
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-modulen
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 pl
[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 r
6 matches
Mail list logo
