Re: python-central vs python-support
On Mon, 05 Jun 2006, Raphael Hertzog wrote: On Sun, 04 Jun 2006, Joe Wreschnig wrote: policy is. So here's *my* attempt at summarizing the BoF, based on your first mail and responses, and independent of the tools used: 1) Public modules and extensions should support all available Python versions, using a single binary package. 2) A new control field, XC-Python-Version will be used to determine what versions of Python a module supports. 3) The tight upper bound on module dependencies will be removed, provided the module actually works on future versions of Python. The upper bound on extension dependencies will not, because then they wouldn't work. 4) python2.x-* virtual packages are to be used only when necessary, but packages can provide them regardless. 5) Private modules and applications should use some way to support more than one Python version, if possible. Is this accurate? 1), 3), and 4) contridict your original email, but match what you told me this time. Yes, this is a good summary IMO, however I don't remember if we discussed point 5. Joe, could you integrate all this in the real document of the python policy? Any other volunteer for that task? We'll have to announce those changes to all developers and we really need to have the real policy updated. I'm not sure where the reference document is. Matthias? In any case, it should be moved on a public svn server. Since pkg-python is still not used, I would suggest the python-modules SVN. 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: 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
Re: 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]
Re: 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
Re: [DebianGIS] Re: thuban strict wxPython version check?
On Thu, Jun 08, 2006 at 05:22:33PM +0200, Bernhard Herzog wrote: Paul Wise [EMAIL PROTECTED] writes: I'm wondering what the following check from Thuban/version.py is for? Is the wxWidgets ABI really so fragile that wxProj breaks on new minor 2.6.X versions or new 2.4.X versions? Surely using the soname to do version checks with the normal shared library support is enough? The symptom people often see when using Thuban with a different wxWidgets version -- even when it's only a different minor version -- is that it segfaults as soon as it tries to actually render a map on the screen. In the past there were enough problem reports from users about this for us to put in the version check so that users would at least get a meaningful error message instead of just a segfault. The reason for the crashes is that wxproj accesses wxPython objects at the C++-level to extract the corresponding wxWidgets object so that it can call wxWidgets methods directly. That way, Thuban can render data read from e.g. a shapefile without having to funnel the data through Python which improves rendering speed considerably. Unfortunately, this means that the wxWidgets object used by wxproj has been created by the wxWidgets library wxPython is linked with and that may be different from the one wxproj is linked with. The libraries may differ in the layout of the classes and/or virtual tables depending on the version and perhaps compile time options. Bernhard I'm not a python addicted, but I suspect this issue should be managed at python-wxgtk2.4 level. Incompatibilities in ABIs should be managed using different source packages to avoid conflicts. I'm CC to d-python list for analysis... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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
