Bug#370833: New dh_python proposal
Le mardi 13 juin 2006 à 15:23 -0400, Joey Hess a écrit : (FWIW, I began ignoring this issue when the politics and constant advocacy and pressure became too annoying to bother with, and I expect to ignore it for at least another couple of weeks. Unfortunatly that means that to avoid either trampeling over or blessing your NMU, I won't be able to release any other debhelper fixes in that timeframe either.) If it is really slowing things down this way, I will ask for the removal of python-support. Although it is a better and simpler solution than python-central, I don't want to delay the move to python2.4 several more month. We've already waited too much for Matthias to start moving. -- .''`. 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
Bug#370833: New dh_python proposal
I don't particularly mind that you've chosen to NMU debhelper. However, I can't guarantee that I will preserve the interfaces that you've added to dh_python in a backwards compatible way when I get around to looking at it. (FWIW, I began ignoring this issue when the politics and constant advocacy and pressure became too annoying to bother with, and I expect to ignore it for at least another couple of weeks. Unfortunatly that means that to avoid either trampeling over or blessing your NMU, I won't be able to release any other debhelper fixes in that timeframe either.) -- see shy jo signature.asc Description: Digital signature
Bug#370833: New dh_python proposal
Joey Hess writes: I don't particularly mind that you've chosen to NMU debhelper. However, I can't guarantee that I will preserve the interfaces that you've added to dh_python in a backwards compatible way when I get around to looking at it. (FWIW, I began ignoring this issue when the politics and constant advocacy and pressure became too annoying to bother with, and I expect to ignore it for at least another couple of weeks. Unfortunatly that means that to avoid either trampeling over or blessing your NMU, I won't be able to release any other debhelper fixes in that timeframe either.) could you agree in temporarily/permanently splitting out dh_python from debhelper? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370833: New dh_python proposal
On Mon, 12 Jun 2006, Raphael Hertzog wrote: On Mon, 12 Jun 2006, Raphael Hertzog wrote: I would love to have this fixed by today's dinstall. That's why I prepared the attached NMU, please just send an OK and I'll upload it (of course, feel free to do it yourself in a maintainer upload). Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). Just to avoid confusion, this would mean uploading between 18:00 and 19:00 UTC today (in about 9.5 hours). And for extra-care, here's the package for testing: http://people.debian.org/~hertzog/python/ http://people.debian.org/~hertzog/python/debhelper_5.0.37.1_all.deb Please test and report me ASAP any problem with it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#370833: New dh_python proposal
Coin, Raphael Hertzog [EMAIL PROTECTED] writes: Without any answer from you, I might upload it right before dinstall (depending on the opinion of other involved people). This is perfectly reasonnable. -- Marc Dequènes (Duck) pgpSLnZRmgvP3.pgp Description: PGP signature
Bug#370833: New dh_python proposal
On Sun, 11 Jun 2006, Dafydd Harries wrote: Ar 10/06/2006 am 21:50, ysgrifennodd Raphael Hertzog: I have written dh_pycentral and dh_pysupport which will take care of the byte-compilation of the modules and integration with the respective tools. Those should be integrated in their respective packages (after review by their maintainer). Please no. Let's not have multiple solutions to the same problem. This wastes the time of each maintainer of a Python package who needs to work out whether they need to use dh_python, dh_pycentral, dh_pysupport or some combination of the three. That's why we have a policy document, to say what they need to do and how they can do it. If you want your modules to be byte-compiled you need to use either dh_pycentral or dh_pysupport. Then, you will always have to use dh_python to generate the right dependencies/provides/Python-Version field. It really isn't *that* complicated. We are on the verge of having a greatly improved Python policy, having that policy implemented, and finally having Python 2.4 as default in Debian. This reluctance to settle on a standard way of installing modules is slowing our progress on all three fronts, and release time draws ever nearer. What is slowing our progress is the refusal to let the time decide between python-central and/or python-support. There's no consensus here and if you need to make a choice, your only possibility is to request the technical committee to make a choice. And the technical committee needs time as well. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#370833: New dh_python proposal
* Raphael Hertzog ([EMAIL PROTECTED]) [060611 10:00]: What is slowing our progress is the refusal to let the time decide between python-central and/or python-support. There's no consensus here and if you need to make a choice, your only possibility is to request the technical committee to make a choice. And the technical committee needs time as well. Especially as I don't see the good reason why we cannot have two competing implementations. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370833: New dh_python proposal
On 10/06/2006 Joe Wreschnig wrote: Please reconsider. If you don't integrate that version now, we'll most probably do the switch to python2.4 in the next days and we'll replace dh_python calls by dh_python2 calls (integrated for example in the python package) or we'll remove call to dh_python in favor of dh_pycentral (existing and in python-central) / dh_pythonsupport (not existing but quick to create). Please don't prefix non-debhelper commands with dh_ if you do this. Call it deb_pysupport/deb_pycentral or something, and likewise please don't mess with #DEBHELPER#. Stomping all over the namespace because you were rejected from the package per se seems to miss Joey's point. # apt-file search /usr/bin/dh_ | grep -v debhelper cli-common-dev: usr/bin/dh_clideps cli-common-dev: usr/bin/dh_installcligac cli-common-dev: usr/bin/dh_makeclilibs defoma: usr/bin/dh_installdefoma desktop-profiles: usr/bin/dh_installlisting dh-buildinfo: usr/bin/dh_buildinfo dh-consoledata: usr/bin/dh_consoledata dh-kpatches: usr/bin/dh_installkpatches dh-lisp: usr/bin/dh_lisp dh-make: usr/bin/dh_make gaim-dev: usr/bin/dh_gaim gjdoc: usr/bin/dh_javadoc haskell-devscripts: usr/bin/dh_haskell haskell-devscripts: usr/bin/dh_haskell_build haskell-devscripts: usr/bin/dh_haskell_buildinst haskell-devscripts: usr/bin/dh_haskell_install haskell-devscripts: usr/bin/dh_haskell_prep mono-xsp-base: usr/bin/dh_installxsp ruby-pkg-tools: usr/bin/dh_rdoc tex-common: usr/bin/dh_installtex upx-ucl: usr/bin/dh_upx xml-core: usr/bin/dh_installxmlcatalogs obviously it is already common practice to integrate dh_* helper scripts in packages other than debhelper. ... jonas signature.asc Description: Digital signature
Bug#370833: New dh_python proposal
* Andreas Barth ([EMAIL PROTECTED]) [060611 10:13]: * Raphael Hertzog ([EMAIL PROTECTED]) [060611 10:00]: What is slowing our progress is the refusal to let the time decide between python-central and/or python-support. There's no consensus here and if you need to make a choice, your only possibility is to request the technical committee to make a choice. And the technical committee needs time as well. Especially as I don't see the good reason why we cannot have two competing implementations. We had some discussion on that on IRC. Basically, if there are technical problems with the policy or one of the tools, please bring them up. My current understanding is however, that people agree enough now. If that is corrcet, we should go forward using the new tools. I would like to see the new python2.3/2.4/python-central going to testing before changes occur that could delay that, but that's rather a footnote (and should only delay by a few days). It is still possible to review the situation in 6 months or so and deprecate one of the tools. Raphael, it might be a good idea to make a better visible summary of the status somewhere (and also of the new policy and of the changes). If you think I could be a help, I would be willing to help there. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370833: New dh_python proposal
On Fri, 09 Jun 2006, Joey Hess wrote: Raphael Hertzog wrote: Because Matthias and Josselin do not (or can't or don't want to) work together. I tried my best to fill the gap. :-/ I appreciate your work, but I am not comfortable supporting two competing implementations in debhelper. Please reconsider. If you don't integrate that version now, we'll most probably do the switch to python2.4 in the next days and we'll replace dh_python calls by dh_python2 calls (integrated for example in the python package) or we'll remove call to dh_python in favor of dh_pycentral (existing and in python-central) / dh_pythonsupport (not existing but quick to create). And if we go that way, then we loose the possibility to move easily to a single unified helper tool in the future since all packages would have again to be modified to reuse dh_python. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#370833: New dh_python proposal
On Sat, 2006-06-10 at 09:08 +0200, Raphael Hertzog wrote: On Fri, 09 Jun 2006, Joey Hess wrote: Raphael Hertzog wrote: Because Matthias and Josselin do not (or can't or don't want to) work together. I tried my best to fill the gap. :-/ I appreciate your work, but I am not comfortable supporting two competing implementations in debhelper. Please reconsider. If you don't integrate that version now, we'll most probably do the switch to python2.4 in the next days and we'll replace dh_python calls by dh_python2 calls (integrated for example in the python package) or we'll remove call to dh_python in favor of dh_pycentral (existing and in python-central) / dh_pythonsupport (not existing but quick to create). Please don't prefix non-debhelper commands with dh_ if you do this. Call it deb_pysupport/deb_pycentral or something, and likewise please don't mess with #DEBHELPER#. Stomping all over the namespace because you were rejected from the package per se seems to miss Joey's point. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#370833: New dh_python proposal
On Sat, 10 Jun 2006, Raphael Hertzog wrote:
I appreciate your work, but I am not comfortable supporting two
competing implementations in debhelper.
Please reconsider. If you don't integrate that version now, we'll most
probably do the switch to python2.4 in the next days and we'll replace
dh_python calls by dh_python2 calls (integrated for example in the python
package) or we'll remove call to dh_python in favor of dh_pycentral (existing
and in python-central) / dh_pythonsupport (not existing but quick to
create).
After discussing with doko and vorlon, I decided to change dh_python to
respect your wish (it's understandable).
Please find a new dh_python attached. This one supports neither
python-central nor python-support. It does however all the substvars
handling required by the new Python policy and is still compatible with
the old policy.
Please integrate that one.
I have written dh_pycentral and dh_pysupport which will take care of the
byte-compilation of the modules and integration with the respective tools.
Those should be integrated in their respective packages (after review by
their maintainer).
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
#!/usr/bin/perl -w
=head1 NAME
dh_python - calculates python dependencies and adds postinst and prerm python
scripts
=cut
use strict;
use File::Find;
use Debian::Debhelper::Dh_Lib;
=head1 SYNOPSIS
Bdh_python [SIdebhelper options] [B-n] [B-V Iversion] [SImodule
dirs ...]
=head1 DESCRIPTION
dh_python is a debhelper program that is responsible for generating the
${python:Depends} substitutions and adding them to substvars files. It
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 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.
=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}.
If some modules need to be byte-compiled at install time, appropriate
postinst and prerm scripts will be generated. If already byte-compiled
modules are found, they are removed.
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
=item Imodule dirs
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/$PACKAGE, /usr/share/$PACKAGE,
/usr/lib/games/$PACKAGE,
/usr/share/games/$PACKAGE and /usr/lib/python?.?/site-packages.
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
If the .py files your package ships are meant to be used by a specific
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.
=back
=head1 CONFORMS TO
Debian policy, version 3.5.7
Python policy, version 0.3.7
=cut
init();
my $python = 'python';
# The current python major version
my $python_major;
my $python_version = `$python -V 21`;
if (! defined $python_version || $python_version eq ) {
error(Python is not installed, aborting. (Probably forgot to
Build-Depend on python.));
}
elsif ($python_version =~
Bug#370833: New dh_python proposal
Ar 10/06/2006 am 21:50, ysgrifennodd Raphael Hertzog: I have written dh_pycentral and dh_pysupport which will take care of the byte-compilation of the modules and integration with the respective tools. Those should be integrated in their respective packages (after review by their maintainer). Please no. Let's not have multiple solutions to the same problem. This wastes the time of each maintainer of a Python package who needs to work out whether they need to use dh_python, dh_pycentral, dh_pysupport or some combination of the three. We are on the verge of having a greatly improved Python policy, having that policy implemented, and finally having Python 2.4 as default in Debian. This reluctance to settle on a standard way of installing modules is slowing our progress on all three fronts, and release time draws ever nearer. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370833: New dh_python proposal
On Fri, 09 Jun 2006, Raphael Hertzog wrote:
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.
OK, I did test it myself finally this morning (with regular feedback from
Matthias as well). It leads me to some corrections so please find an
updated (and final!) dh_python in attachment.
Matthias and Josselin, please say clearly here in the bug report that
you are OK with this dh_python implementation so that Joey can confidently
integrate it in debhelper RSN.
[ Joey Hess ]
So I'm confused, why do we have competing implementations here?
Because Matthias and Josselin do not (or can't or don't want to) work
together. I tried my best to fill the gap. :-/
FWIW, my opinion is that the BoF at Debconf clearly decided of a new
python policy but didn't explicitely choose an implementation. At that
time, only python-support was working and integrated in unstable.
We all knew doko's ambitious plan with python-central and since we didn't
discuss the implementation, there was a kind of implicit agreement that we
would use whatever would be ready in time for the python2.4 switch
(with many people convincend that python-central wouldn't be ready in
time).
Now, we have two working python helper tool but python-central has
not yet been widely tested.
If you check the code you'll see that the python-(support|central)
specific code is very limited and mainly consists on adding postinst
script snippet and dependencies when needed. I tried my best to have a
dh_python which is agnostic but still effective. :-)
I hope you understand better the situation and I really hope that you'll
accept this dh_python so that we can effectively start moving to python2.4
by default RSN.
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 12:45:52.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
Bug#370833: New dh_python proposal
Raphael Hertzog writes: On Fri, 09 Jun 2006, Raphael Hertzog wrote: 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. OK, I did test it myself finally this morning (with regular feedback from Matthias as well). It leads me to some corrections so please find an updated (and final!) dh_python in attachment. Matthias and Josselin, please say clearly here in the bug report that you are OK with this dh_python implementation so that Joey can confidently integrate it in debhelper RSN. checked and tested together with Raphael. Looks OK for me. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370833: New dh_python proposal
Le vendredi 09 juin 2006 à 14:07 +0200, Raphael Hertzog a écrit : OK, I did test it myself finally this morning (with regular feedback from Matthias as well). It leads me to some corrections so please find an updated (and final!) dh_python in attachment. Matthias and Josselin, please say clearly here in the bug report that you are OK with this dh_python implementation so that Joey can confidently integrate it in debhelper RSN. I haven't had the time to test this implementation in complicated cases, but I have read it extensively and I believe it does what it needs to do. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Bug#370833: New dh_python proposal
Raphael Hertzog wrote: Because Matthias and Josselin do not (or can't or don't want to) work together. I tried my best to fill the gap. :-/ I appreciate your work, but I am not comfortable supporting two competing implementations in debhelper. Sorry. -- see shy jo signature.asc Description: Digital signature
Bug#370833: 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 =
