Re: FTWCA python-central vs pyhton-support
Le jeudi 08 juin 2006 à 23:22 -0300, Gustavo Noronha Silva a écrit : > 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. The release team has make it clear we can release with python 2.3 as the default if Matthias doesn't upload it soon enough. Which of course would be the best for Ubuntu. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: FTWCA python-central vs pyhton-support
On Fri, 09 Jun 2006, Josselin Mouette wrote: > Le jeudi 08 juin 2006 à 23:22 -0300, Gustavo Noronha Silva a écrit : > > 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. > > The release team has make it clear we can release with python 2.3 as the > default if Matthias doesn't upload it soon enough. Yes but the release team also wants python2.4 otherwise Steve wouldn't have participated in the BoF to find a solution. We'll make it because we're (almost) ready now: - python-central is available in unstable for test - a new satisfying dh_python is ready (I'm currently testing it) > Which of course would be the best for Ubuntu. Please stop that. It's plainly wrong. Matthias has to handle the divergence between Ubuntu's python and Debian's python and it's unrewarding grunt work for him... that's why he pushed so hard python-central because then transitions are easier for everybody (inclugin him when he has to manage a Ubuntu transition). But the simplest for him is when Ubuntu and Debian use the same python version. So please stop spreading FUD. 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 c
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
