Re: Upstream Makefile, debian/rules, eggs, building and installing
On Wed, 21 Mar 2007, Ben Finney wrote: > How should the Debian packaging files interact with this? Examples > I've seen for using python-central have the egg being built in the > Debian-specific debian/rules targets, but this is clearly duplication > if the upstream Makefile already builds an egg. Please be specific... tell us which examples you are referring to. We can't discuss in general when you might refer to an exception and when you might have misunderstood what you've read. > In normal (non-Debian) usage of Setuptools, a user will generate an > egg that is specific to a Python version, and install that; this isn't > what's needed by python-central, though. But surely the answer isn't > essentially duplication of the build-an-egg step between the upstream > Makefile and debian/rules ? We're using a feature of setuptools to provide eggs as unpacked directory trees instead of a single archive. This doesn't duplicate anything and it doesn't mean that we build eggs manually. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream Makefile, debian/rules, eggs, building and installing
On Wed, 21 Mar 2007, Raphael Hertzog wrote: > On Wed, 21 Mar 2007, Ben Finney wrote: > > How should the Debian packaging files interact with this? Examples > > I've seen for using python-central have the egg being built in the > > Debian-specific debian/rules targets, but this is clearly duplication > > if the upstream Makefile already builds an egg. > > Please be specific... tell us which examples you are referring to. We > can't discuss in general when you might refer to an exception and when you > might have misunderstood what you've read. BTW, applicable examples for your case: $ grep-available -F Depends 'python-central' -a -F Architecture 'all' -s Package Package: python-sqlobject Package: bzr Package: python-pexpect Package: python-serial Package: reportbug Package: python-optcomplete Package: python-setuptools Package: python-formencode (bzr and reportbug are applications mainly and not modules, they're not good examples for you) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[RFC] hijacking of python-soappy
[ Please Cc:-me on replies, I'm not subscribed to d-python ] Hi all, python-soappy has been maintained by NMUs for the last 3 years. Since I needed the new upstream release (which integrates 2 patches from the team I'm working with), after discussing the issue on #debian-python I decided to hijack the package and to change the maintainer to the debian python modules team (with me as an uploader of course). The result of my draft work is available at: svn+ssh://svn.debian.org/svn/python-modules/packages/python-soappy (or svn://svn.debian.org/python-modules/packages/python-soappy) the .orig.tar.gz tarball can be obtained from sourceforge or, without the need of renaming it, from: http://www.bononia.it/~zack/stalla/python-soappy_0.12.0~rc1.orig.tar.gz Since it's an hijacking and since I'm rather a newcomer at python packaging I would be glad if someone can have a look at my work to check I didn't do anything (too) stupid. Especially comments from the people who performed the numerous NMUs in the last years would be appreciated. I will be testing the package in the next few days and then I'll upload it in the delayed queue. Many thanks in advance, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Upstream Makefile, debian/rules, eggs, building and installing
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Wed, 21 Mar 2007, Ben Finney wrote: > > How should the Debian packaging files interact with this? Examples > > I've seen for using python-central have the egg being built in the > > Debian-specific debian/rules targets, but this is clearly > > duplication if the upstream Makefile already builds an egg. > > Please be specific... tell us which examples you are referring to. I was referred to http://wiki.debian.org/DebianPythonFAQ> which, for python-central, directs me to http://python-modules.alioth.debian.org/python-central_howto.txt>. That document lists three example packages: = # package without .so files apt-get source pyparallel # package with .so files apt-get source python-imaging # package with .so files and Egg support apt-get source pyenchant = I looked at 'pyparallel' because I am not packaging extensions, and at 'pyenchant' because I'm packaging with Egg support. > We're using a feature of setuptools to provide eggs as unpacked > directory trees instead of a single archive. This doesn't duplicate > anything and it doesn't mean that we build eggs manually. It does mean that the build step of the existing package, with its 'python ./setup.py --various --options bdist_egg', is discarded, and needs to be done again (in a different way) for the Debian packaging. -- \ "Welchen Teil von 'Gestalt' verstehen Sie nicht? [What part of | `\ 'gestalt' don't you understand?]" -- Karsten M. Self | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposed update to the python policy
Hi,
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the "current" keyword;
* making Provides: meaningful in the case of inter-module
dependencies, as discussed at Debconf;
* fixes to the erroneous python-support section.
Comments anyone?
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
--- python-policy.sgml.orig 2007-03-21 20:00:04.0 +0100
+++ python-policy.sgml 2007-03-21 19:57:22.0 +0100
@@ -24,7 +24,7 @@
Joe Wreschnig
[EMAIL PROTECTED]
- version 0.4.1.0
+ version 0.4.2pre
This document describes the packaging of Python within the
@@ -288,15 +288,12 @@
one of the following:
XS-Python-Version: all
-XS-Python-Version: current
-XS-Python-Version: current, >= X.Y
XS-Python-Version: >= X.Y
XS-Python-Version: >= A.B, << X.Y
XS-Python-Version: A.B, X.Y
Where "all" means the package supports any Python version
- available, and "current" means it supports Debian's current
- Python version. Explicit Versions or version ranges can also
+ available. Explicit Versions or version ranges can also
be used.
@@ -304,11 +301,11 @@
XB-Python-Version: ${python:Versions}
- The python:Versions is substituted by the supported Python
+ The python:Versions variable is substituted by the supported Python
versions of the binary package, based on
XS-Python-Version. (If you are not using
- dh_python you will need to handle this
- substitution yourself.) The format of the field
+ dh_pysupport or dh_pycentral,
+ you will need to handle this yourself.) The format of the field
XB-Python-Version is the same as the
XS-Python-Version field for packages not containing
extensions. Packages with extensions must list the versions
@@ -330,9 +327,7 @@
in must depend on "python
(>= X.Y)". If they
require other modules to work, they must depend on the
- corresponding python-foo. They must not
- depend on
- any pythonX.Y-foo.
+ corresponding python-foo.
Packaged modules available for one particular version of Python must
@@ -347,19 +342,27 @@
Provides
- Provides in packages of the form
- python-foo must be specified,
- if the package contains an extension for more than one
- python version. Provides should also be added on request of
- maintainers who depend on a non-default python version.
+ Packages of the form python-foo, that
+ contain modules or extensions for one or more python versions,
+ should specify a Provides: for all
+ pythonX.Y-foo corresponding
+ to the python versions they support.
- 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.
+ If they do so and also need other modules, they must depend on all
+ corresponding pythonX.Y-bar
+ for each version they support, in addition to the
+ python-bar dependency. These dependencies
+ should be generated at build time, and should be based on the
+ Python-Depends control field:
+
+Depends: ${python:Depends}
+Python-Depends: python-bar (>= 1.2.3)
+Provides: ${python:Provides}
+
+ In the binary package, the generated dependencies should include the
+ contents of the Python-Depends field, plus all corresponding
+ pythonX.Y-bar.
@@ -546,9 +549,7 @@
If you use either python-support or
python-central you must additionally
- Build-Depend on those. If you are using dh_python
- at all, you must Build-Depend on python, as
- debhelper does not depend on it.
+ Build-Depend on those.
@@ -567,11 +568,8 @@
The python-support system provides a simple way to
bytecompile pure Python modules and manage dependencies. It
- integrates with debhelper. When using
- python-support, you should install your modules
- to /usr/share/python-support/package
- rather than the standard Python directories. python-support
- will then handle compiling the modules and making
+ integrates with debhelper; python-support
+ will handle compiling the modules and making
appropriate symbolic links for installed Python versions to
find them,
substitute ${python:Depends}, ${python:Versions},
@@ -579,29 +577,26 @@
manage bytecompilation in your postinst/prerm.
- To use it, call dh_pysupport
- before dh_python, and make sure you've
- installed the modules in the right place:
+ To use it, call dh_pysupport in the binary tar
Re: Proposed update to the python policy
Le mercredi 21 mars 2007 à 20:22 +0100, Josselin Mouette a écrit : > I think it's time to update the python policy with the progress that has > been made in how we build python packages. The proposed diff is > attached. In summary it includes: > * the deprecation of the "current" keyword; > * making Provides: meaningful in the case of inter-module > dependencies, as discussed at Debconf; > * fixes to the erroneous python-support section. * and deprecation of dh_python, of course. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Proposed update to the python policy
[Josselin Mouette, 21.03.2007] > * the deprecation of the "current" keyword; "current" keyword is deprecated? Why? I'm using it a lot and I like it... -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpeuiDfwvZtU.pgp Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007, Josselin Mouette wrote: > I think it's time to update the python policy with the progress that has > been made in how we build python packages. The proposed diff is > attached. In summary it includes: > * the deprecation of the "current" keyword; > * making Provides: meaningful in the case of inter-module > dependencies, as discussed at Debconf; > * fixes to the erroneous python-support section. Looks good; this obviously implies that python-central will need to match the new dependency functionalities. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
module package naming
Hi, the debian python policy states that module packages should be named python-foo, foo being the module name. I intend to package PySyck, which contains the module/package 'syck', which is also in python-syck (AFAICT PySyck is basically a fork of the upstream bindings). Would python-pysyck be a reasonable name for the package, or is something else more adequate ? Regards, Thomas Jollans pgpDEOjwD81lm.pgp Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 08:28:47PM +0100, Piotr Ożarowski wrote: > [Josselin Mouette, 21.03.2007] > > * the deprecation of the "current" keyword; > > "current" keyword is deprecated? Why? I'm using it a lot and I like > it... What are you using it for exactly ? I mean, please give an example, with an actual package, that would be okay. Because I'm 100% sure that current is (1) not a good idea (2) not needed in fact. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpxxGDbXy9Dt.pgp Description: PGP signature
Re: Proposed update to the python policy
[Pierre Habouzit, 21.03.2007]
> On Wed, Mar 21, 2007 at 08:28:47PM +0100, Piotr Ożarowski wrote:
> > "current" keyword is deprecated? Why? I'm using it a lot and I like
> > it...
>
> What are you using it for exactly ? I mean, please give an example,
> with an actual package, that would be okay. Because I'm 100% sure that
> current is (1) not a good idea (2) not needed in fact.
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will work only with
python2.5 and above, I can Build-depend on python-dev (>= 2.5) | python2.5-dev
and set XS-Python-Version: to "current, >=2.5"
example packages: emma, pypar2, gaupol, griffith
BTW: I like rest of your diffs (I don't know much about "Python-Depends"
control field, though)
PS Is it the right time to think about merging python-{central,support}
or is it to early for that?
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgp9ebcVJNaDY.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
> [Pierre Habouzit, 21.03.2007]
> > On Wed, Mar 21, 2007 at 08:28:47PM +0100, Piotr Ożarowski wrote:
> > > "current" keyword is deprecated? Why? I'm using it a lot and I like
> > > it...
> >
> > What are you using it for exactly ? I mean, please give an example,
> > with an actual package, that would be okay. Because I'm 100% sure that
> > current is (1) not a good idea (2) not needed in fact.
>
> it's useful for Python applications that need specific Python version.
>
> f.e. if current Python version is 2.4 and my app. will work only with
> python2.5 and above, I can Build-depend on python-dev (>= 2.5) | python2.5-dev
> and set XS-Python-Version: to "current, >=2.5"
>
> example packages: emma, pypar2, gaupol, griffith
could you explain me in which part 'current' is helping you here ? I
missed to understand what asking for:
XS-Python-Version: >= 2.5
would haven't achieved. In fact, what I understand from current, is
that it designs python2.4 for now, so how is that accurate for your
example ?
I mean, try to set:
XS-Python-Version: >= 2.5
and please tell me what it changed in the package you built with that.
I'm curious. Btw I don't think you answered the question properly, as
you didn't explained the think current achieves for you. And honnestly,
it's not a trick question, I mean it, what is its purpose for you. I
don't see its usefulness, but I may miss a thing :)
> BTW: I like rest of your diffs (I don't know much about "Python-Depends"
> control field, though)
>
> PS Is it the right time to think about merging python-{central,support}
> or is it to early for that?
It's only thinking for now, and I think it's really the moment to
think about further plans for lenny obviously.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpcgOXFuCLdd.pgp
Description: PGP signature
Is supermarket
Experience a Charging Bull CEO AMERICA INC Sym-CEOA Currently : 6 Cents, CHEAP!!! Add this to your radar AN ALL AMERICAN COMPANY Get IN Before the rush TOMORROW you or anything,'' Iverson said. ''It just feels good. It just feels like . For once, it was the opposition that did both. Notes: Iverson's season-high didn't see any way we were going to get back into the game.'' Anthony had 19 was easily the Nuggets' best game of the season. The Nuggets shot 68 percent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed update to the python policy
[Pierre Habouzit, 21.03.2007]
> On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
> > it's useful for Python applications that need specific Python version.
> >
> > f.e. if current Python version is 2.4 and my app. will work only with
> > python2.5 and above, I can Build-depend on python-dev (>= 2.5) |
> > python2.5-dev
> > and set XS-Python-Version: to "current, >=2.5"
> >
> > example packages: emma, pypar2, gaupol, griffith
>
> could you explain me in which part 'current' is helping you here ? I
> missed to understand what asking for:
I could swear that with this keyword pycentral will set hashbang to
python2.5 (with python2.4 set as default) but apparently it doesn't (I
just tested it with emma), it just sets Depends: to "python (>=2.5) |
python2.5", just like pysupport do with "2.5-" in debian/pyversions
file.
is it a bug in both pycentral and pysupport?
Anyway, if it does not change hashbang then OK, it's deprecated.
> > PS Is it the right time to think about merging python-{central,support}
> > or is it to early for that?
>
> It's only thinking for now, and I think it's really the moment to
> think about further plans for lenny obviously.
How about a vote about which one should be used in Lenny? I mean, both
systems are doing basically the same thing now. I'm using python-central
in most of my packages (I use python-support in some co-maintained
packages) - I moved to pycentral because pysupport was not handling
Python extensions at the time I needed it. It does handle it now so if
pysupport wins the vote I will be able to easily move to the new default
system.
BTW: I would really love to see pyversions file content moved back to
debian/control file, so that using grep-dctrl would be a lot easier.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgprRv2yrWq58.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote: > I think it's time to update the python policy with the progress that has > been made in how we build python packages. The proposed diff is > attached. In summary it includes: > * the deprecation of the "current" keyword; So with current deprecated, what is the solution for a package which wants to build a single binary extension for the current python version in a package named python-foo, with no support for other versions of python returned by pyversions -s? > * making Provides: meaningful in the case of inter-module > dependencies, as discussed at Debconf; Do the helpers implement this, or is this going to be a policy that packages can't actually comply with? -- 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]
Re: Proposed update to the python policy
Le mercredi 21 mars 2007 à 14:44 -0700, Steve Langasek a écrit : > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote: > > > I think it's time to update the python policy with the progress that has > > been made in how we build python packages. The proposed diff is > > attached. In summary it includes: > > * the deprecation of the "current" keyword; > > So with current deprecated, what is the solution for a package which wants > to build a single binary extension for the current python version in a > package named python-foo, with no support for other versions of python > returned by pyversions -s? If this is a public extension, this goes completely against the spirit of the policy and should not be allowed. It just means more packages having to migrate simultaneously with python-defaults. > > * making Provides: meaningful in the case of inter-module > > dependencies, as discussed at Debconf; > > Do the helpers implement this, or is this going to be a policy that packages > can't actually comply with? python-support 0.6 already implements this. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote: > Le mercredi 21 mars 2007 à 14:44 -0700, Steve Langasek a écrit : > > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote: > > > I think it's time to update the python policy with the progress that has > > > been made in how we build python packages. The proposed diff is > > > attached. In summary it includes: > > > * the deprecation of the "current" keyword; > > So with current deprecated, what is the solution for a package which wants > > to build a single binary extension for the current python version in a > > package named python-foo, with no support for other versions of python > > returned by pyversions -s? > If this is a public extension, this goes completely against the spirit > of the policy and should not be allowed. It just means more packages > having to migrate simultaneously with python-defaults. It's not against the spirit of what was discussed in Mexico, it's just against the spirit of what you personally think. -- 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]
Re: Proposed update to the python policy
[Steve Langasek, 21.03.2007] > So with current deprecated, what is the solution for a package which wants > to build a single binary extension for the current python version in a > package named python-foo, with no support for other versions of python > returned by pyversions -s? I think depending on python-dev for current only modules/apps and python-all-dev for the rest should be enough (if both systems will recognize it correctly, I mean also: "python-dev(>=2.5)|python2.5-dev" ) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp8mCFvBDkzM.pgp Description: PGP signature
Re: Proposed update to the python policy
Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit : > On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote: > > If this is a public extension, this goes completely against the spirit > > of the policy and should not be allowed. It just means more packages > > having to migrate simultaneously with python-defaults. > > It's not against the spirit of what was discussed in Mexico, it's just > against the spirit of what you personally think. I'm not the one who suddenly declared all packages complying with the "old" policy RC-buggy. Do I understand that we can drop all the multi-version stuff now? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 10:38:30PM +0100, Piotr Ożarowski wrote:
> [Pierre Habouzit, 21.03.2007]
> > On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
> > > it's useful for Python applications that need specific Python version.
> > >
> > > f.e. if current Python version is 2.4 and my app. will work only with
> > > python2.5 and above, I can Build-depend on python-dev (>= 2.5) |
> > > python2.5-dev
> > > and set XS-Python-Version: to "current, >=2.5"
> > >
> > > example packages: emma, pypar2, gaupol, griffith
> >
> > could you explain me in which part 'current' is helping you here ? I
> > missed to understand what asking for:
>
> I could swear that with this keyword pycentral will set hashbang to
> python2.5 (with python2.4 set as default) but apparently it doesn't (I
> just tested it with emma), it just sets Depends: to "python (>=2.5) |
> python2.5", just like pysupport do with "2.5-" in debian/pyversions
> file.
>
> is it a bug in both pycentral and pysupport?
No it was my point: current does nothing. In fact, for the very
example you propose it serves no end at all :)
> > > PS Is it the right time to think about merging python-{central,support}
> > > or is it to early for that?
> >
> > It's only thinking for now, and I think it's really the moment to
> > think about further plans for lenny obviously.
>
> How about a vote about which one should be used in Lenny? I mean, both
vote sucks, I'd really prefer to see a real solution be drafted. IMHO
the vote should be the last resort.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgprQUvf3vSIs.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 11:03:37PM +0100, Josselin Mouette wrote: > Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit : > > On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote: > > > If this is a public extension, this goes completely against the spirit > > > of the policy and should not be allowed. It just means more packages > > > having to migrate simultaneously with python-defaults. > > It's not against the spirit of what was discussed in Mexico, it's just > > against the spirit of what you personally think. > I'm not the one who suddenly declared all packages complying with the > "old" policy RC-buggy. WTF? Neither did the release team. > Do I understand that we can drop all the multi-version stuff now? Who's "we"? -- 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]
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 02:44:29PM -0700, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote: > > > I think it's time to update the python policy with the progress that has > > been made in how we build python packages. The proposed diff is > > attached. In summary it includes: > > * the deprecation of the "current" keyword; > > So with current deprecated, what is the solution for a package which wants > to build a single binary extension for the current python version in a > package named python-foo, with no support for other versions of python > returned by pyversions -s? I must say I quite agree with Josselin here. What would be the purpose of a package like this ? Either we comply with the idea behind the policy, meaning that a package is built for as many supported python version we can, either we don't. If we don't, I don't see the purpose of the policy alltogether. If we do, then current is quite broken IMHO. I mean, we have basically 3 types of packages (there is more, but for what I will try to expose, we can fold things onto those three). * packages written in pure python: those enter in the scope of the policy as soon as they support (at least) the default python version. In that case, well, there is nothing special to do, it spoils nothing (neither build time nor space) to support every python version available. * packages with private binary modules: those (with or without "current") can only be built for one version of python at a time. For them current is meaningless. In fact it's even confusing, because when you look at a package that was built with a pythonX.Y as default, current meant X.Y at that time. If you look it after having switched to a pythonX'.Y' the "current" you see has another meaning (and yes pycentral uses it in XB-P-V, and IMHO it's a bug). * packages with binary public modules. Those are the one that indeed may spoil a bit of resources (space on the user hard drive, and time as we basically build the package twice). Though, if we have concerns about speed or time for _public_ modules (meaning the very modules that are meant to be used by the programmer right?) we fail completely to follow the spirit of the "new" (that is not so new right now ;p) policy. So here current seems if not broken, nor useless, at least against the idea of the policy. Is there anything that I miss with those explanations ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpxYpbSB6Wlh.pgp Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 03:14:27PM -0700, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 11:03:37PM +0100, Josselin Mouette wrote: > > Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit : > > > On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote: > > > > If this is a public extension, this goes completely against the spirit > > > > of the policy and should not be allowed. It just means more packages > > > > having to migrate simultaneously with python-defaults. > > > > It's not against the spirit of what was discussed in Mexico, it's just > > > against the spirit of what you personally think. > > > I'm not the one who suddenly declared all packages complying with the > > "old" policy RC-buggy. > > WTF? Neither did the release team. > > > Do I understand that we can drop all the multi-version stuff now? > > Who's "we"? Please (and it's meant as much to both of you) that part of the thread is going nowhere useful. We can avoid this easily, shall we ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp0DpVKLrfwH.pgp Description: PGP signature
Re: module package naming
On Wed, Mar 21, 2007 at 08:46:35PM +0100, Thomas Jollans wrote: > Hi, > > the debian python policy states that module packages should be named > python-foo, foo being the module name. I intend to package PySyck, which > contains the module/package 'syck', which is also in python-syck (AFAICT > PySyck is basically a fork of the upstream bindings). > Would python-pysyck be a reasonable name for the package, or is something > else > more adequate ? If the module name is syck and that there already is a python-syck then you're going into trouble, because you will have conflicts between the two. you should call a package python-$(foo) if to use it you have to "import $(foo)". At least it's what the policy says, and it's IMHO sane. And if you have two different libraries providing the same module $(foo) they can't be installed at the same time. In that case, well, I don't really know what to say. Having two things not really the same called the same suck. I hardly see someone fork the openssl and say that the new lib would be called libssl too. That would be disastrous. That's the same here IMHO. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjqGRKVJLej.pgp Description: PGP signature
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote: > [Steve Langasek, 21.03.2007] > > So with current deprecated, what is the solution for a package which wants > > to build a single binary extension for the current python version in a > > package named python-foo, with no support for other versions of python > > returned by pyversions -s? > I think depending on python-dev for current only modules/apps and > python-all-dev for the rest should be enough (if both systems will > recognize it correctly, I mean also: "python-dev(>=2.5)|python2.5-dev" ) No, this has nothing to do with the question of being able to get the version number of, and build binary extensions for, the current version of python. -- 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]
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: > On Wed, Mar 21, 2007 at 02:44:29PM -0700, Steve Langasek wrote: > > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote: > > > I think it's time to update the python policy with the progress that has > > > been made in how we build python packages. The proposed diff is > > > attached. In summary it includes: > > > * the deprecation of the "current" keyword; > > So with current deprecated, what is the solution for a package which wants > > to build a single binary extension for the current python version in a > > package named python-foo, with no support for other versions of python > > returned by pyversions -s? > I must say I quite agree with Josselin here. What would be the purpose > of a package like this ? Either we comply with the idea behind the > policy, meaning that a package is built for as many supported python > version we can, either we don't. No. That may have been the idea behind *Josselin's* policy, but that was never "the" idea behind the policy that was being proposed and discussed early last year on this list. > If we don't, I don't see the purpose of the policy alltogether. Allowing transitions between default versions of python without package renames, bypassing NEW, allowing binNMUable transitions, and generally simplifying the python upgrade path for users across releases. Supporting multiple binary extensions in a single python-foo package is a tool that *facilitates* that goal, but it was *never* supposed to be mandatory. There are extensions with no/few reverse-dependencies and a small install base, such that supporting multiple versions of python is useless archive bloat. Evidently everyone has lost sight of this as a result of Josselin's process hijacking. Oh well. > * packages with binary public modules. Those are the one that indeed > may spoil a bit of resources (space on the user hard drive, and time > as we basically build the package twice). Though, if we have > concerns about speed or time for _public_ modules (meaning the very > modules that are meant to be used by the programmer right?) we fail > completely to follow the spirit of the "new" (that is not so new > right now ;p) policy. So here current seems if not broken, nor > useless, at least against the idea of the policy. No, it's your ideas of what the policy should be that are broken. -- 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]
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: > > If we don't, I don't see the purpose of the policy alltogether. > > Allowing transitions between default versions of python without package > renames, bypassing NEW, allowing binNMUable transitions, and generally > simplifying the python upgrade path for users across releases. > > Supporting multiple binary extensions in a single python-foo package is a > tool that *facilitates* that goal, but it was *never* supposed to be > mandatory. There are extensions with no/few reverse-dependencies and a > small install base, such that supporting multiple versions of python is > useless archive bloat. > > Evidently everyone has lost sight of this I see. What does "current" has to do with it then ? in the current state of affairs, nothing prevent the maintainer to only build the package for $(pyversions -d) only, which would be: (1) binNMUable (2) only built for the current python version as per spec of what you want to achieve. I think I don't say anything foolish here, and that current was not a requirement. Though, I know what you will argue next, it's that you need (as a RM) to be able to compute the list of packages needing to be queued for binNMU. I've not evaluated yet if current helps here or not (I don't think so, but I've nothing to backup that assertion yet, so I wont say anything until I've a good and minimal solution to propose). > as a result of Josselin's process hijacking. Oh well. Bleh, I think we can avoid that part :) I don't want to point fingers, but to find solutions. Really. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXiV1CCpJFv.pgp Description: PGP signature
Re: module package naming
On Wednesday 21 March 2007 23:26, Pierre Habouzit wrote: > On Wed, Mar 21, 2007 at 08:46:35PM +0100, Thomas Jollans wrote: > > Hi, > > > > the debian python policy states that module packages should be named > > python-foo, foo being the module name. I intend to package PySyck, which > > contains the module/package 'syck', which is also in python-syck (AFAICT > > PySyck is basically a fork of the upstream bindings). > > Would python-pysyck be a reasonable name for the package, or is something > > else more adequate ? > > If the module name is syck and that there already is a python-syck > then you're going into trouble, because you will have conflicts between > the two. > > you should call a package python-$(foo) if to use it you have to > "import $(foo)". At least it's what the policy says, and it's IMHO sane. > And if you have two different libraries providing the same module $(foo) > they can't be installed at the same time. In that case, well, I don't > really know what to say. Having two things not really the same called > the same suck. I hardly see someone fork the openssl and say that the > new lib would be called libssl too. That would be disastrous. That's the > same here IMHO. Yes, obviously the packages would have to conflict. They cannot be installed at the same time, but they could be available at the same time, IMHO. There is also the possibility of creating a virtual package python-syck and have libsyck-python and pysyck or something provide it, which is, IMHO, ugly. There is also the option of only having one in the distribution, which should be PySyck for having more features. This would mean chucking the official binding out of debian, which I am not entirely comfortable with either. I am very new to debian packaging and a bit lost here, which is why I'm asking debian-python for advice ;-) Thomas Jollans pgp4bCz8zQ17b.pgp Description: PGP signature
Re: Proposed update to the python policy
[Steve Langasek, 21.03.2007]
> On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
> > I think depending on python-dev for current only modules/apps and
> > python-all-dev for the rest should be enough (if both systems will
> > recognize it correctly, I mean also: "python-dev(>=2.5)|python2.5-dev" )
>
> No, this has nothing to do with the question of being able to get the
> version number of, and build binary extensions for, the current version of
> python.
how about this:
^^^
case 1: emma - python application that installs private module
Build-Depends: python-dev (>= 2.5) | python2.5-dev
XS-Python-Version: >=2.5
Architecture: all
case 2: emma - python application that installs private module (and lets
say it is providing private python extension as well)
Build-Depends: python-dev (>= 2.4) | python2.4-dev
XS-Python-Version: >=2.4
Architecture: any
case 3: sqlalchemy - python module
Build-Depends: python-all-dev
XS-Python-Version: >=2.3
Architecture: all
case 4: pywavelets - python extension
Build-Depends: python-all-dev
XS-Python-Version: >=2.4
Architecture: any
and I expect python- to:
case 1:
* compile it for current Python version only (no binNMU needed after
default Python version change, just recompile the module on user's
machine)
* 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"
* change hashbang if needed (and remember about it [also in in
XB-Python-Version
probably] - what if Python version from versioned hashbang will be
removed from supported Python versions?)
case 2:
* as above, except binNMU is needed after default python version change, no
need
to remember hashbang change
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
case 4:
* as above, binNMU needed
* XB-Python-Version: >=2.4
* Provides: python2.4-wavelets
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpm37LHCXcce.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
> [Steve Langasek, 21.03.2007]
> > On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
> > > I think depending on python-dev for current only modules/apps and
> > > python-all-dev for the rest should be enough (if both systems will
> > > recognize it correctly, I mean also: "python-dev(>=2.5)|python2.5-dev" )
> >
> > No, this has nothing to do with the question of being able to get the
> > version number of, and build binary extensions for, the current version of
> > python.
>
> how about this:
> ^^^
>
> case 1: emma - python application that installs private module
> Build-Depends: python-dev (>= 2.5) | python2.5-dev
> XS-Python-Version: >=2.5
>
> Architecture: all
>
> case 2: emma - python application that installs private module (and lets
> say it is providing private python extension as well)
> Build-Depends: python-dev (>= 2.4) | python2.4-dev
> XS-Python-Version: >=2.4
>
> Architecture: any
>
>
> case 3: sqlalchemy - python module
> Build-Depends: python-all-dev
> XS-Python-Version: >=2.3
>
> Architecture: all
>
> case 4: pywavelets - python extension
> Build-Depends: python-all-dev
> XS-Python-Version: >=2.4
>
> Architecture: any
>
>
> and I expect python- to:
>
>
> case 1:
> * compile it for current Python version only (no binNMU needed after
> default Python version change, just recompile the module on user's
> machine)
for a pure module or a binary one ?
> * 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
> * change hashbang if needed (and remember about it [also in in
> XB-Python-Version
> probably] - what if Python version from versioned hashbang will be
> removed from supported Python versions?)
hashbang should always be /usr/bin/python as soon as the default
version is supported. We implicitely assume that as soon as a X.Y python
is supported, next version will. This is safe for 99% of the packages.
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.
> case 2:
> * as above, except binNMU is needed after default python version change, no
> need
> to remember hashbang change
A default python change only requires to binNMU packages that have
private binary modules. _or_ packages with binary extensions that were
only built for the old default version and not others.
So for your example, indeed, you have to build only for $(pyversions -s).
> 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.
> case 4:
> * as above, binNMU needed
> * XB-Python-Version: >=2.4
> * Provides: python2.4-wavelets
no binNMU is needed here either for a default python change. It is
recommended for a python version removal (to avoid to waste space) and
needed for the introduction of a new python (to support the new one).
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpz9r8cZemBg.pgp
Description: PGP signature
Re: Proposed update to the python policy
Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit : > > If we don't, I don't see the purpose of the policy alltogether. > > Allowing transitions between default versions of python without package > renames, bypassing NEW, allowing binNMUable transitions, and generally > simplifying the python upgrade path for users across releases. How does the broken "current" semantics help with any of these goals? > Supporting multiple binary extensions in a single python-foo package is a > tool that *facilitates* that goal, but it was *never* supposed to be > mandatory. There are extensions with no/few reverse-dependencies and a > small install base, such that supporting multiple versions of python is > useless archive bloat. This has absolutely nothing to do with what we are discussing. The decision to build for one or all python versions belongs to the maintainer, and the build process should reflect it. But by expressing "current" instead of the real list of supported python versions, you completely lose track of which python versions are actually supported by the source package. > Evidently everyone has lost sight of this as a result of Josselin's process > hijacking. Oh well. I'm interested to know which process I have hijacked. I have not contributed to python policy changes since the "new policy" madness has started, and I haven't forced anyone to implement things. I've just implemented a tool that does things *correctly* and helps other maintainers in this maelstrom of incorrect documentation and blurry packaging processes. Or maybe you're saying that just because it's easier to point someone as the sole responsible for the current fiasco than to find real, working solutions. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: module package naming
Le jeudi 22 mars 2007 à 00:06 +0100, Thomas Jollans a écrit : > There is also the option of only having one in the distribution, which should > be PySyck for having more features. This would mean chucking the official > binding out of debian, which I am not entirely comfortable with either. If it is compatible with the official bindings and has more features, this sounds like the way to go, although it also depends on upstream plans for python-syck. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote: > On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote: > > On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: > > > If we don't, I don't see the purpose of the policy alltogether. > > Allowing transitions between default versions of python without package > > renames, bypassing NEW, allowing binNMUable transitions, and generally > > simplifying the python upgrade path for users across releases. > > Supporting multiple binary extensions in a single python-foo package is a > > tool that *facilitates* that goal, but it was *never* supposed to be > > mandatory. There are extensions with no/few reverse-dependencies and a > > small install base, such that supporting multiple versions of python is > > useless archive bloat. > I see. What does "current" has to do with it then ? in the current > state of affairs, nothing prevent the maintainer to only build the > package for $(pyversions -d) only, which would be: > (1) binNMUable > (2) only built for the current python version as per spec of what you > want to achieve. In the original proposal, 'current' was the flag to tell the packaging tools that pyversions -d *should* be used. There is of course nothing that stops a maintainer from invoking pyversions -d manually; the question is, how will doing so fit into the python policy, will there be support for automating this in the helper tools, and will packages that do this (and are therefore binNMUable for python transitions) be automatically detectable from the Sources and/or Packages files? > Though, I know what you will argue next, it's that you need (as a RM) > to be able to compute the list of packages needing to be queued for > binNMU. Exactly. :) > I've not evaluated yet if current helps here or not (I don't think so, but > I've nothing to backup that assertion yet, so I wont say anything until > I've a good and minimal solution to propose). Ok, I look forward to hearing this proposal. -- 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]
Re: Proposed update to the python policy
[Pierre Habouzit, 22.03.2007]
> On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
> > [Steve Langasek, 21.03.2007]
> > > On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
> > > > I think depending on python-dev for current only modules/apps and
> > > > python-all-dev for the rest should be enough (if both systems will
> > > > recognize it correctly, I mean also: "python-dev(>=2.5)|python2.5-dev" )
> > >
> > > No, this has nothing to do with the question of being able to get the
> > > version number of, and build binary extensions for, the current version of
> > > python.
> >
> > how about this:
> > ^^^
> >
> > case 1: emma - python application that installs private module
> > Build-Depends: python-dev (>= 2.5) | python2.5-dev
> > XS-Python-Version: >=2.5
> >
> > Architecture: all
> >
> > case 2: emma - python application that installs private module (and lets
> > say it is providing private python extension as well)
> > Build-Depends: python-dev (>= 2.4) | python2.4-dev
> > XS-Python-Version: >=2.4
> >
> > Architecture: any
> >
> >
> > case 3: sqlalchemy - python module
> > Build-Depends: python-all-dev
> > XS-Python-Version: >=2.3
> >
> > Architecture: all
> >
> > case 4: pywavelets - python extension
> > Build-Depends: python-all-dev
> > XS-Python-Version: >=2.4
> >
> > Architecture: any
> >
> >
> > and I expect python- to:
> >
> >
> > case 1:
> > * compile it for current Python version only (no binNMU needed after
> > default Python version change, just recompile the module on user's
> > machine)
>
> for a pure module or a binary one ?
I mean just recompile .pyc files (for new default Python version), leave
package untouched
> > * 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
How will python- know to recompile it just for one version and not
for all supported ones?
>
> > * change hashbang if needed (and remember about it [also in in
> > XB-Python-Version
> > probably] - what if Python version from versioned hashbang will be
> > removed from supported Python versions?)
>
> hashbang should always be /usr/bin/python as soon as the default
> version is supported. We implicitely assume that as soon as a X.Y python
> is supported, next version will. This is safe for 99% of the packages.
>
> 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.
What if my application needs python2.X where X = Y+1 and Y is default
one? (I had this problem with gaupol when python2.3 was default, and
"current, >2.4" worked just fine!)
> > 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.
I mean recompile pyc files only of course, not the whole package (as I
said: no binNMU )
> > case 4:
> > * as above, binNMU needed
> > * XB-Python-Version: >=2.4
> > * Provides: python2.4-wavelets
>
> no binNMU is needed here either for a default python change. It is
> recommended for a python version removal (to avoid to waste space) and
> needed for the introduction of a new python (to support the new one).
new supported python version is available, package provides .so files
and you say no binNMU is needed?
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpK5zbY9XiLN.pgp
Description: PGP signature
Re: Proposed update to the python policy
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]
Re: Proposed update to the python policy
On Wed, Mar 21, 2007 at 04:50:30PM -0700, Steve Langasek wrote: > On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote: > > On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote: > > > On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote: > > > > If we don't, I don't see the purpose of the policy alltogether. > > > > Allowing transitions between default versions of python without package > > > renames, bypassing NEW, allowing binNMUable transitions, and generally > > > simplifying the python upgrade path for users across releases. > > > > Supporting multiple binary extensions in a single python-foo package is a > > > tool that *facilitates* that goal, but it was *never* supposed to be > > > mandatory. There are extensions with no/few reverse-dependencies and a > > > small install base, such that supporting multiple versions of python is > > > useless archive bloat. > > > I see. What does "current" has to do with it then ? in the current > > state of affairs, nothing prevent the maintainer to only build the > > package for $(pyversions -d) only, which would be: > > (1) binNMUable > > (2) only built for the current python version as per spec of what you > > want to achieve. > > In the original proposal, 'current' was the flag to tell the packaging tools > that pyversions -d *should* be used. There is of course nothing that stops > a maintainer from invoking pyversions -d manually; Okay I see. As a coder, I don't like it then, and I feel reinforced in my gut dislike of that field. "current" is declarative, and does not says anything about what the packager really put in his debian/rules. If he does not writes what has to be to multi-build the package, and that he does not puts current, well, the package basically will only be built for current. As you already acknowledge the reverse situation also holds. And as a matter of a fact, maintainers do not seem to understand what current is for, Piotr python2.5-only package is a very good example of this IMHO. > the question is, how will > doing so fit into the python policy, will there be support for automating > this in the helper tools, and will packages that do this (and are therefore > binNMUable for python transitions) be automatically detectable from the > Sources and/or Packages files? like I say later, I knew it was what really matters for you. And IMHO it's really more interesting that the dh_py* tools explains what has really been built. They already do the job to generate the correct substs for python:Depends and python:Provides, so basically, the code to detect that exists. One just has to make it clear in the Packages.gz files. Like I said, I don't really think Sources.gz are relevant, as it's declarative from the maintainer PoV. But like said, I've not yet thought about all the consequences yet, and I do not know what's needed or not. I've the suspicion that XB-P-V could indeed be the way to go (even if for packages with modules Provides: show that information already), but I'm not sure that the current use of XB-P-V carries all the information we need. > > Though, I know what you will argue next, it's that you need (as a RM) > > to be able to compute the list of packages needing to be queued for > > binNMU. > > Exactly. :) > > > I've not evaluated yet if current helps here or not (I don't think so, but > > I've nothing to backup that assertion yet, so I wont say anything until > > I've a good and minimal solution to propose). > > Ok, I look forward to hearing this proposal. Thanks. I'll try to make this proposal driven from our needs, and not trying to advantage this or that implementation of the dh_py* helpers, which was the ground of the argument when I joined this (mess ?) half a year ago. I think with your explanations, I quite understand the requirements from the user and packager point of view (NEW, number of packages efficiency, etc...), and I believe the sole other need is the ease to deal with transitions from the RM PoV and for that it needs to answer the 3 questions: * what should be binNMUed for a python version removal (assuming it was not default btw ;P), that one is easy IMHO: basically nothing _needs_ to, but: + packages with a strong dependency on that pythonX.Y and _no_ python dependency have to be dropped altogether (or likely need porting and are not binNMUable) ; + for space efficiency we could think of binNMUing every package that has built a public module for that particular python version. Here, XB-P-V is not needed if we have the Provides that is mandatory (and that is what Joss proposes, and I think it's sane anyway). * what should be done for a default python change: here concerned packages are: + packages with private binary extensions, + packages built only for the "current" python version. * what should be done for a new python: here concerned packages
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote:
> [Pierre Habouzit, 22.03.2007]
> > On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski 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
>
> How will python- know to recompile it just for one version and not
> for all supported ones?
Why would you prevent the user to bytecompile your package for every
python version he choose to install ? I see the point to avoid archive
bloat in not building every binary extension. But locally ? Well, that
seems wrong. Really.
Especially since the dh_py* tools will only byte-compile code for
python versions that are supported _and_ installed on the user machine.
For pure python packages "current" does not makes sense.
> > > * change hashbang if needed (and remember about it [also in in
> > > XB-Python-Version
> > > probably] - what if Python version from versioned hashbang will be
> > > removed from supported Python versions?)
> >
> > hashbang should always be /usr/bin/python as soon as the default
> > version is supported. We implicitely assume that as soon as a X.Y python
> > is supported, next version will. This is safe for 99% of the packages.
> >
> > 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.
>
> What if my application needs python2.X where X = Y+1 and Y is default
> one? (I had this problem with gaupol when python2.3 was default, and
> "current, >2.4" worked just fine!)
then you ask for 2.4- and the dh_* tool will deal with things for the
dependencies. It's up to you to fix the hashbangs properly. But again,
dh_py* tools won't help you a lot for packages that do not _at least_
support pyversions -d. You will need to do some extra work.
But IMHO the whole point of that policy is that a move to a new python
(python2.5 here) can be done very fast, before there is too many
packages that only work with python2.5, meaning that there will be few
packages in that case, and that it will only be a transitionnal
situation for them.
> > > case 4:
> > > * as above, binNMU needed
> > > * XB-Python-Version: >=2.4
> > > * Provides: python2.4-wavelets
> >
> > no binNMU is needed here either for a default python change. It is
> > recommended for a python version removal (to avoid to waste space) and
> > needed for the introduction of a new python (to support the new one).
>
> new supported python version is available, package provides .so files
> and you say no binNMU is needed?
You definitely seem to have misread me.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpypgIZ5cTsR.pgp
Description: PGP signature
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 01:17:17AM +0100, Pierre Habouzit wrote: > > In the original proposal, 'current' was the flag to tell the packaging tools > > that pyversions -d *should* be used. There is of course nothing that stops > > a maintainer from invoking pyversions -d manually; > Okay I see. As a coder, I don't like it then, and I feel reinforced in > my gut dislike of that field. "current" is declarative, and does not > says anything about what the packager really put in his debian/rules. That's fine. I'm not wedded to the, ah, "current" implementation; my concern is that it not be gutted from the policy because of concerns about the implementation, instead of finding a non-buggy solution. > If he does not writes what has to be to multi-build the package, and > that he does not puts current, well, the package basically will only be > built for current. And in that case, do all of the helpers correctly calculate the Provides based on the contents of the binary packages? > And as a matter of a fact, maintainers do not seem to understand what > current is for, Piotr python2.5-only package is a very good example of > this IMHO. Well, information surrounding 'current' is certainly muddled at present, but I don't think that points to a technical flaw. > > the question is, how will > > doing so fit into the python policy, will there be support for automating > > this in the helper tools, and will packages that do this (and are therefore > > binNMUable for python transitions) be automatically detectable from the > > Sources and/or Packages files? > like I say later, I knew it was what really matters for you. And IMHO > it's really more interesting that the dh_py* tools explains what has > really been built. They already do the job to generate the correct > substs for python:Depends and python:Provides, so basically, the code to > detect that exists. Yes, so automation of the package builds themselves is addressed, with or without 'current'. > One just has to make it clear in the Packages.gz files. Like I said, I > don't really think Sources.gz are relevant, as it's declarative from the > maintainer PoV. I can't think of any reason it would be a problem to have this information in Packages only. > But like said, I've not yet thought about all the consequences yet, > and I do not know what's needed or not. I've the suspicion that XB-P-V > could indeed be the way to go (even if for packages with modules > Provides: show that information already), but I'm not sure that the > current use of XB-P-V carries all the information we need. AIUI the current use of XB-P-V, as endorsed by the python policy, indicates what versions of python the package has been built for, which is not all that relevant for binNMUs; the same information can already be extracted (though less easily) from the provides/depends. What is needed is a description of what will happen to the package if a buildd is *attempted* against a particular version of python. > Thanks. I'll try to make this proposal driven from our needs, and not > trying to advantage this or that implementation of the dh_py* helpers, > which was the ground of the argument when I joined this (mess ?) half a > year ago. I think with your explanations, I quite understand the > requirements from the user and packager point of view (NEW, number of > packages efficiency, etc...), and I believe the sole other need is the > ease to deal with transitions from the RM PoV and for that it needs to > answer the 3 questions: > * what should be binNMUed for a python version removal (assuming it > was not default btw ;P), that one is easy IMHO: basically nothing > _needs_ to, but: > + packages with a strong dependency on that pythonX.Y and _no_ > python dependency have to be dropped altogether (or likely need > porting and are not binNMUable) ; > + for space efficiency we could think of binNMUing every package > that has built a public module for that particular python > version. Here, XB-P-V is not needed if we have the Provides that > is mandatory (and that is what Joss proposes, and I think it's > sane anyway). In addition to space efficiency, this should be done to ensure that packages are in a consistent state at release time, so that we don't risk a security update significantly changing the contents of one of these packages. > * what should be done for a default python change: here concerned > packages are: > + packages with private binary extensions, > + packages built only for the "current" python version. Yes, I believe that's correct. > * what should be done for a new python: here concerned packages are > _only_ packages that build public binary modules for more than the > "current" python. Here again, XB-P-V does not seems required if the > Provides is, they provide the same information, except for the "I'm > only built for current and if you binNMU me I
Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 12:47:17AM +0100, Josselin Mouette wrote: > Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit : > > > If we don't, I don't see the purpose of the policy alltogether. > > Allowing transitions between default versions of python without package > > renames, bypassing NEW, allowing binNMUable transitions, and generally > > simplifying the python upgrade path for users across releases. > How does the broken "current" semantics help with any of these goals? The question I asked was, what is this policy going to do to support the use case that 'current' was designed to address? Your answer appears to be 'nothing'. That's not acceptable. Deprecating the 'current' keyword without offering an alternative that's at least as usable for the intended purpose as 'current' is, is a step in the wrong direction. > > Evidently everyone has lost sight of this as a result of Josselin's process > > hijacking. Oh well. > I'm interested to know which process I have hijacked. I have not > contributed to python policy changes since the "new policy" madness has > started, and I haven't forced anyone to implement things. I've just > implemented a tool that does things *correctly* and helps other > maintainers in this maelstrom of incorrect documentation and blurry > packaging processes. You implemented a tool that *ignored* some of the use cases that went into the initial policy, among them the case for 'current'. -- 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]
Re: Proposed update to the python policy
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote: > > How will python- know to recompile it just for one version > > and not for all supported ones? > > Why would you prevent the user to bytecompile your package for every > python version he choose to install ? I see the point to avoid archive > bloat in not building every binary extension. But locally ? Well, that > seems wrong. Really. One reason I can think of: The package fails to build on Python earlier than a particular version, and the user has Python versions older than that concurrently installed. -- \ "Don't worry about what anybody else is going to do. The best | `\ way to predict the future is to invent it." -- Alan Kay | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed update to the python policy
Le jeudi 22 mars 2007 à 16:12 +1100, Ben Finney a écrit : > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > Why would you prevent the user to bytecompile your package for every > > python version he choose to install ? I see the point to avoid archive > > bloat in not building every binary extension. But locally ? Well, that > > seems wrong. Really. > > One reason I can think of: The package fails to build on Python > earlier than a particular version, and the user has Python versions > older than that concurrently installed. This kind of information is already stored in the binary package, with XB-Python-Version or /usr/share/python-support/$package/.version. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
