Re: FTWCA python-central vs pyhton-support
On Thu, 2006-06-08 at 09:33 +0200, Raphael Hertzog wrote: [ Please don't keep the BTS cced if you reply unless you want to express a concern about the dh_python implementation suggested by the bug ] Hello everybody, Matthias has been working on integrating python-central support in dh_python and submitted #370833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370833 This dh_python will use python-central for any binary package with a XB-Python-Version: field. There's no optional python-support either. So anyone unhappy with python-central should really come up with another dh_python implementation RSN. Previously we rolled back Joss's patch because Matthias didn't like it, and it took him several months to write a new one. Plus, Joss's patch actually worked, and formed the basis of a system that's now in common use (python-support). Since then, a new policy -- from Matthias -- has made that patch invalid. It's unfair (at best) to demand someone write a replacement Real Soon Now, when this *is* a replacement, and not soon at all, and pycentral got a head start because it designed the new policy. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: FTWCA python-central vs pyhton-support
Please don't Cc me. I am on the list. On Thu, 2006-06-08 at 23:05 +0200, Matthias Klose wrote: Joe Wreschnig writes: On Thu, 2006-06-08 at 09:33 +0200, Raphael Hertzog wrote: [ Please don't keep the BTS cced if you reply unless you want to express a concern about the dh_python implementation suggested by the bug ] Hello everybody, Matthias has been working on integrating python-central support in dh_python and submitted #370833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370833 This dh_python will use python-central for any binary package with a XB-Python-Version: field. There's no optional python-support either. So anyone unhappy with python-central should really come up with another dh_python implementation RSN. Previously we rolled back Joss's patch because Matthias didn't like it, no, not because I didn't like it, because it didn't work. It did work, it just didn't work like you wanted it to. python-support works. There are packages in the archive using it to support multiple Python versions and remove upper dependency bounds. Since then, a new policy -- from Matthias -- has made that patch invalid. It's unfair (at best) to demand someone write a replacement Real Soon Now, when this *is* a replacement, and not soon at all, and pycentral got a head start because it designed the new policy. If you start speaking about fairness, please consider that python-support was uploaded to unstable without any discussion, with dh_python forcing python-support for every rebuild of a package. I did consider that. We rolled back Joss's patch. Why should yours get special treatment? In #370833 Joss claims that it was decided at debconf to use python-support for python modules. That's plain wrong. I do not understand why somebody tries to make a point by telling nonsense. I've heard some degree of conflicting claims from everyone who was at the BoF. Many packages are *already* using python-support for Python modules. So in that sense, it was decided long before the BoF to use python-support. I didn't see any updates for python-support in the past months, Then you're blind or stupid. python-support 0.2 was uploaded on April 26th, 2006, and contained many changes requested by the RMs and maintainers. Joss made two maintenance uploads during May. It is being used by many Python packages already in unstable. It's not complete, and it's certainly not up-to-date with the specifications *you* want. But Joss is actively developing it, and to claim otherwise is incredibly disingenuous. Joss refused to change python-support, Joss refused to change python-support to work like you wanted it to. therefore I did move on with python-central, which is now in unstable as well. He started it! Sorry, that argument doesn't work. Just because Joss rushed ahead with python-support in a way you didn't like doesn't mean you get to rush ahead with python-central (and python itself) in a way that several participants of this list have stated they don't like. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: FTWCA python-central vs pyhton-support
Le jeudi 08 juin 2006 à 23:05 +0200, Matthias Klose a écrit : Previously we rolled back Joss's patch because Matthias didn't like it, no, not because I didn't like it, because it didn't work. Bullshit. If you start speaking about fairness, please consider that python-support was uploaded to unstable without any discussion, with dh_python forcing python-support for every rebuild of a package. It was uploaded to unstable. Something that should have happened way earlier for python-support if you wanted people to test it. In #370833 Joss claims that it was decided at debconf to use python-support for python modules. That's plain wrong. I restate it. That's what was said and that's what we agreed upon. Anyway, I don't care whether you acknowledge it or not, as you seem to be going all by yourself when it comes to python packaging. You are trying to push into Debian things you introduced in Ubuntu, against other packagers' opinion, just because this is already in Ubuntu. But Debian decisions are not for Ubuntu to make. I do not understand why somebody tries to make a point by telling nonsense. But sadly, I do understand why somebody is trying to make a point by telling lies. You are trying to make Debian just an outdated copy of Ubuntu, and well, a few lies couldn't hurt. I didn't see any updates for python-support in the past months, The last update has only one month. Do you want to talk about the move of python-defaults to python2.4, which was asked by the release team several months ago, without any action so far? Joss refused to change python-support, You didn't ask anything. But you may note that vorlon asked for several things, which were all implemented in python-support 0.2 on april 29. therefore I did move on with python-central, which is now in unstable as well. I made it clear at debconf that it's not a likely option to support both management tools in the python packages. So your approval of the plan at debconf was also a lie? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: FTWCA python-central vs pyhton-support
Joe Wreschnig writes: Please don't Cc me. I am on the list. On Thu, 2006-06-08 at 23:05 +0200, Matthias Klose wrote: Joe Wreschnig writes: On Thu, 2006-06-08 at 09:33 +0200, Raphael Hertzog wrote: [ Please don't keep the BTS cced if you reply unless you want to express a concern about the dh_python implementation suggested by the bug ] Hello everybody, Matthias has been working on integrating python-central support in dh_python and submitted #370833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370833 This dh_python will use python-central for any binary package with a XB-Python-Version: field. There's no optional python-support either. So anyone unhappy with python-central should really come up with another dh_python implementation RSN. Previously we rolled back Joss's patch because Matthias didn't like it, no, not because I didn't like it, because it didn't work. It did work, it just didn't work like you wanted it to. python-support works. There are packages in the archive using it to support multiple Python versions and remove upper dependency bounds. Since then, a new policy -- from Matthias -- has made that patch invalid. It's unfair (at best) to demand someone write a replacement Real Soon Now, when this *is* a replacement, and not soon at all, and pycentral got a head start because it designed the new policy. If you start speaking about fairness, please consider that python-support was uploaded to unstable without any discussion, with dh_python forcing python-support for every rebuild of a package. I did consider that. We rolled back Joss's patch. Why should yours get special treatment? Did I say that? It's not complete, and it's certainly not up-to-date with the specifications *you* want. But Joss is actively developing it, and to claim otherwise is incredibly disingenuous. Joss refused to change python-support, Joss refused to change python-support to work like you wanted it to. Introducing a tool which is only usable for a subset of the packages and introducing dependency errors is ... If you call that not liking, I can live with it. therefore I did move on with python-central, which is now in unstable as well. He started it! Sorry, that argument doesn't work. No, python-support did have the same deficiencies that the old python-central from Bastian did have. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New dh_python proposal
On Thu, 08 Jun 2006, Raphael Hertzog wrote:
This dh_python will use python-central for any binary package with a
XB-Python-Version: field. There's no optional python-support either.
So anyone unhappy with python-central should really come up with another
dh_python implementation RSN.
OK I discussed with Josselin and Matthias and came up with the attached
dh_python (patch attached as well).
This dh_python depends neither on python-central nor on python-support but it
can work with both.
It will use python-central if it appears in a build-dependency.
It will use python-support if it detects /usr/share/python-support/$package.
If the XS-Python-Version field is present, it will work following the new
policy otherwise it should follow the old policy.
At least that's the theory. I did some tests on two recent packages with
python-central and python-support. I'd like people to try to recompile
some actual python-related packages modules with that dh_python and check
if it's really enough backwards compatible.
I think we'll be able to move forward when this dh_python is integrated in
debhelper.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--- dh_python.orig 2006-06-08 10:57:59.0 +0200
+++ dh_python 2006-06-09 04:07:56.0 +0200
@@ -21,7 +21,42 @@
will also add a postinst and a prerm script if required.
The program will look at python scripts and modules in your package, and
-will use this information to generate a dependency on python, with the
+will use this information to generate adequate dependencies. There is two
+scenarios: if the package uses the XS-Python-Version field then
+the new policy will be applied, otherwise the old policy will be used.
+
+If dh_python detects python-central in one of the build-dependencies,
+then it will automatically use it: it will be added in the dependencies
+and corresponding postinst/postrm scripts are generated.
+
+If dh_python detects that you have a directory
+/usr/share/python-support/$PACKAGE, then it will automatically generate the
+required postinst/postrm scripts.
+
+=head2 New policy
+
+The XS-Python-Version field (on the source package) defines which Python
+versions are supported by the package. It can be all, current,
+current, = X.Y, a single version (2.3) or a list of versions with
+optional comparison operators (ex: 2.3, 2.4 or = 2.2, 2.5 or
+= 2.4).
+
+The binary packages should have a XB-Python-Version: ${python:Versions}
+field and dh_python will generate the right substvar for that. The
+resulting value can be all for public modules which work with all python
+versions, current for private modules which are always byte-compiled
+with the current python version or a list of of all versions for which the
+extensions have been compiled (ex: 2.3, 2.4). The dependencies are
+adjusted accordingly as well.
+
+Packages with public extensions should also have a Provides:
+${python:Provides} field. The corresponding substvar will indicate
+pythonX.Y-foo, pythonX.Z-foo according to all the extensions
+effectively available in the package.
+
+=head2 Old policy
+
+It looks at scripts and modules in your package and adds a dependency on
python, with the
current major version, or on pythonX.Y if your scripts or modules need a
specific python version. The dependency will be substituted into your
package's control file wherever you place the token ${python:Depends}.
@@ -32,6 +67,8 @@
If you use this program, your package should build-depend on python.
+Note: in the old policy, /usr/lib/site-python is also scanned for modules.
+
=head1 OPTIONS
=over 4
@@ -40,11 +77,10 @@
If your package installs python modules in non-standard directories, you
can make dh_python check those directories by passing their names on the
-command line. By default, it will check /usr/lib/site-python,
-/usr/lib/$PACKAGE, /usr/share/$PACKAGE, /usr/lib/games/$PACKAGE,
+command line. By default, it will check /usr/lib/$PACKAGE,
/usr/share/$PACKAGE, /usr/lib/games/$PACKAGE,
/usr/share/games/$PACKAGE and /usr/lib/python?.?/site-packages.
-Note: only /usr/lib/site-python, /usr/lib/python?.?/site-packages and the
+Note: only /usr/lib/python?.?/site-packages and the
extra names on the command line are searched for binary (.so) modules.
=item B-V Iversion
@@ -53,6 +89,9 @@
pythonX.Y version, you can use this option to specify the desired version,
such as 2.3. Do not use if you ship modules in /usr/lib/site-python.
+With the new policy, this option is mostly deprecated. Use the
+XS-Python-Field to indicate that you're using a specific python version.
+
=item B-n, B--noscripts
Do not modify postinst/postrm scripts.
@@ -85,10 +124,10 @@
}
# The next python version
-my $python_nextversion = $python_version + 0.1;
+my $python_nextversion = next_minor_version($python_version);
my $python_nextmajor = $python_major + 1;
-my @python_allversions =
Re: FTWCA python-central vs pyhton-support
Em Qui, 2006-06-08 às 23:05 +0200, Matthias Klose escreveu: I didn't see any updates for python-support in the past months, Joss refused to change python-support, therefore I did move on with python-central, which is now in unstable as well. I made it clear at debconf that it's not a likely option to support both management tools in the python packages. I know it's being stated and restated, but I think it it important to say it again: python-support is being actively maintained, and had some worries taken into account specially in the 0.2 upload. What I take from this whole issue is, unfortunately, that you are making things harder simply because your personal preference was not the choice of the debian python-related stuff maintainers' de facto consensus. Why don't you work with Joss and us to make python-support better and get this transition going? It's about time, and we're quite close to our deadlines for release, and this whole thing may make etch be delayed or not be the best it could be. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] http://people.debian.org/~kov/ signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
