Re: Python Policy Updates
* Stefano Rivera stefa...@debian.org, 2011-03-24, 15:35:
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.
Correctly using python Provides is expensive. Here's why:
“Provides: python2.X-eggs” is supposed to mean “this package provides
module ‘eggs’ that can be imported with python2.X”. But you can claim
that only if the package depends on the python2.X versions of all other
modules it requires, even if some of them are arch:all! (The policy
doesn't explain this...) Such dependencies are annoying for users and
makes transitions harder.
Therefore, they should be avoided and used only if necessary.
Now, of course, most packages use python Provides wrongly, so it become
essentially meaningless. I will leave as an exercise to the reader to
check how many packages using “Provides: ${python:Provides}” has their
dependencies correct.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324164804.ga5...@jwilk.net
Re: Python Policy Updates
Hi Jakub (2011.03.24_18:48:04_+0200)
But you can claim that only if the package depends on the python2.X
versions of all other modules it requires, even if some of them are
arch:all! (The policy doesn't explain this...)
It does say:
| Packaged modules available for one particular version of Python must
| depend on the corresponding pythonX.Y package instead. If they need
| other modules, they must depend on the corresponding pythonX.Y-foo
| packages, and must not depend on any python-foo.
which sort of covers it.
Such dependencies are annoying for users and makes transitions harder.
More to the point, are they even necessary. When we only provide
something for python 2.6 (when 2.7 is default, before we turf 2.6), that
is a bug, and something to be fixed. If it isn't fixed, the package will
be removed when 2.6 is removed. I don't see how complex
versioned-package-names dependancies help any significant problem here.
I will leave as an exercise to the reader to check how many packages
using “Provides: ${python:Provides}” has their dependencies correct.
I should have made that clearer in my last e-mail. Nobody uses them
correctly. Nobody even uses them for their intended reason.
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110325102450.gc24...@bach.rivera.co.za
Re: Python Policy Updates
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 places where python-support and -central are mentioned,
but not dh_python2. Considering that -central is deprecated, dh_python2
should probably be mentioned in its place.
I'll prepare some patches.
Comments welcome/encouraged, plus additional changes.
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.
I can only see 4 packages depending on one of these virtual packages.
Can we declare it deprecated?
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324133521.ga24...@bach.rivera.co.za
Re: Python Policy Updates
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.
I can only see 4 packages depending on one of these virtual packages.
Can we declare it deprecated?
It was my understanding that this should be used for Python extensions. I
think once we get to pyhton2.7 as the only supported python, it won't matter.
I agree that ${python:Provides} is problematic, so we should consider how we
will approach this problem in Python 3 (I don't know if we can/should handle
it differently).
I'm interested to hear what others have to say on the topic.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103240945.38085.deb...@kitterman.com
Re: Python Policy Updates
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 ${python:Provides}, I don't see
any reason to use this for extensions but not dh_python2 public modules.
I agree that ${python:Provides} is problematic, so we should consider how we
will approach this problem in Python 3 (I don't know if we can/should handle
it differently).
And then there's PEP-384, which may negate this entirely in Python3 for
some packages...
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110324135502.gb24...@bach.rivera.co.za
Re: Python Policy Updates
On Friday, March 18, 2011 10:23:05 pm Scott Kitterman wrote: Today's mail on XB-Python-Version motivates me to send out an overdue call for inputs on further changes to the Python policy. I know that needs to go. What else needs doing? Personally I'd like to concentrate on getting policy for Python 3 to the point that it's possible to produce a correct module or extension package based on what's in the policy without explicitly requiring a helper of any kind. I think dh_python3 is the right helper to have and it's good to use it, but I think policy should fully describe what someone needs to do. I'd particularly appreciate inputs from everyone on this topic. Thanks, Scott K I went through and did a bit of clarification plus added more Python 3 specifics. I don't think it will be controversial. You can find the proposed diff here: http://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults- debian/revision/200 Comments welcome/encouraged, plus additional changes. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103182352.50329.deb...@kitterman.com
