Re: Thoughts on apps supporting multiple versions of python
On Sun, Jun 04, 2006 at 07:16:14PM +0200, Marc Dequènes wrote: Let me reexplain the situation i was talking about with a little graph: python-editobj (using python-support) | python2.3-soya (compiled) | python-ontopofsoya (using python-support) | slune (using current version) A package named python-ontopofsoya should not be depending on just python2.3-soya. It should be depending on python-soya, which can depend on (or provide) python2.3-soya. You're right, i made a hasty shortcut. *IFF* python-ontopofsoya Provides: python2.3-ontopofsoya, then it must also depend on python2.3-soya. If it Provides: python2.4-ontopofsoya, then it must depend on python2.4-soya. But this is merely an expression of existing/previous python policy using virtual packages. In this example python2.3-soya is required because the slune depends on the python package and the current version is 2.3. But since slune does not directly depend on soya, and should be unaware of the ontopofsoya backend (could possibly use pyopengl for example), and python-ontopofsoya cannot arbitrarily choose a soya version, or would choose the default one. python-ontopofsoya *must* depend on python-soya, which must exist as either a virtual or real package. The python-ontopofsoya and python-soya packages must also be available in forms that work with the same version of python, or else python-ontopofsoya is uninstallable (a feature, not a bug). Likewise, if python-ontopofsoya Provides: python2.3-ontopofsoya, python2.4-ontopofsoya, then it must also depend on the packages it needs for *each* version of python it declares support for in order to be useful with that version. I do agree in the form, but: 1) this is quite a mess of Provides and Depends. Yes it can be generated by tools, but this seems quite ugly, and would surely slow down apt logic more and more. I didn't claim that it was pretty, but it is the minimal solution to properly support packages in this configuration. It's also no *more* complex than the current situation with having separate real packages. 2) this solution mean either you need to depends on all versions of dependencies you need, resulting in depending on all python versions in the end, or to introduce plenty of dummy packages, which is clearly what we wanted to avoid, even if it can also be generated. Moreover, going through NEW for new versions is a lot a load for ftpmasters which is absolutely unnecessary. Dummy packages can't be done automatically; if you have to add additional real packages, dummy or not, that's going to require sourceful uploads for editing debian/control, so that's something to avoid if at all possible. After discussing with buxy, it seems it was discussed in DebConf (while there is no real report about this on this list), and having all versions included in the same package was the selected solution to avoid dependency nightmares. Unfortunately, I don't know that anyone was taking notes at the python BoF, we were a bit busy running around and discussing; I was hoping that the videos would be on-line sooner than they apparently will be. -- 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/ signature.asc Description: Digital signature
Re: Thoughts on apps supporting multiple versions of python
Steve Langasek [EMAIL PROTECTED] writes: Wow, what a constructive response. You've surely been on this list for years and must know all the changes that need to be made to Debian's python policy. Why didn't you reply to Bruce's original question with your own superior write-up of this policy? Seems evidence that teamwork with you is impossible. Seems an evidence you don't know anything about me. My work in the GNOME Team *was* appreciated, and AFAIK my work in other teams is too. I recently tested python-support and helped Joss find out problems. Now the latest version is working nicely. This is not a big change, only a minor contribution, but i don't pretend to write a complete perfect policy as you claim. I just don't see any point for discussing such things without involved people. I do ask Joss, Buxy, or any other experimented persons when i need help on Python, not Release Team or X Strike Force people, obviously. For people insterested in python-support related topics, i migrated several of my packages to it with success (namely Slune/Balazar dependencies). Only a minor bug for -x.y versions was left (and fixed recently in 2.2). Some of my packages are blocked into NEW, but editobj is a good example for working packaging. Only the .version file has to be made by hand until dh_python is able to do so, which is not a big job. I wonder how some situations (if existing) may be solved as long as we have unique non-versioned scripts-only packages and compiled modules cohabiting. When for eg python2.4-soya needs editobj, it just depends on python-editobj which provides all versions (so the needed version too), and slune ask for a specific soya version depending on the current Python version, that's easy. Now if i make a library based on soya, using python-support, which would be used between slune and soya, there would be no way to specify from slune through the new library which soya version is needed. So, if my reasoning is correct, until compiled modules are all packaged with every version grouped in the same package (like suggested by doko) or we find another solution, mixing python-support packages and compiled modules could be a problem. -- Marc Dequènes (Duck) pgpQjLYJKqEgj.pgp Description: PGP signature
Re: Thoughts on apps supporting multiple versions of python
Le mercredi 10 mai 2006 à 16:32 +0200, Marc Dequènes a écrit :
I wonder how some situations (if existing) may be solved as long as we
have unique non-versioned scripts-only packages and compiled modules
cohabiting. When for eg python2.4-soya needs editobj, it just depends on
python-editobj which provides all versions (so the needed version too),
and slune ask for a specific soya version depending on the current
Python version, that's easy. Now if i make a library based on soya,
using python-support, which would be used between slune and soya, there
would be no way to specify from slune through the new library which soya
version is needed. So, if my reasoning is correct, until compiled
modules are all packaged with every version grouped in the same package
(like suggested by doko) or we find another solution, mixing
python-support packages and compiled modules could be a problem.
As Steve suggested, this can be solved by introducing a new variable
named ${python:Provides} in dh_python, which will read the .version as
well. Then, python-editobj will have a
Provides: python2.3-editobj, python2.4-editobj
and python2.4-soya will need a
Depends: python2.4, python2.4-editobj
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
Re: Thoughts on apps supporting multiple versions of python
Coin Joss,
Josselin Mouette [EMAIL PROTECTED] writes:
As Steve suggested, this can be solved by introducing a new variable
named ${python:Provides} in dh_python, which will read the .version as
well. Then, python-editobj will have a
Provides: python2.3-editobj, python2.4-editobj
and python2.4-soya will need a
Depends: python2.4, python2.4-editobj
Where my python-ontopofsoya library between soya and slune (i should
have given it a name) here ? I was probably unclear. The situation
you're trying to solve seems to me to carry no problem since
python-editobj will for sure provides all supported python versions
(python-support magic) and pythonx.y-soya cannot be built if the
corresponding python version is not in the archive. Soya is currently
depending on editobj this way without problem, and working with 2.3 and
2.4 packages (slune and balazar).
Let me reexplain the situation i was talking about with a little graph:
python-editobj (using python-support)
|
python2.3-soya (compiled)
|
python-ontopofsoya (using python-support)
|
slune (using current version)
In this example python2.3-soya is required because the slune depends
on the python package and the current version is 2.3. But since slune
does not directly depend on soya, and should be unaware of the
ontopofsoya backend (could possibly use pyopengl for example), and
python-ontopofsoya cannot arbitrarily choose a soya version, or would
choose the default one. This scheme is only working if soya has a dummy
package depending on the current version and slune is using the default
python. This is true for slune but balazar needs 2.4 and would not be
able to work. Happily, there is no ontopofsoya module, but this is a
test case.
--
Marc Dequènes (Duck)
pgpGpZciELjxT.pgp
Description: PGP signature
Re: Thoughts on apps supporting multiple versions of python
Coin, Steve Langasek [EMAIL PROTECTED] writes: Any summaries, partial specs, top level descriptions, particularly good explanations of the stumbling blocks, etc., available for reading? https://wiki.ubuntu.com/PythonRoadmap Is this Ubuntu roadmap of any concern for Debian ? Is doko not able to make proposal and discuss it with the Debian Python Maintainers ? Seems another evidence a team work with this guy is impossible. http://wiki.debian.org/IRC/debian-tech/Logs/20051120-python-policy As i see, you've got many questions for which many people on this list surely know the unswer for years. Why then do you discuss the policy with people not involved in the Python packaging ? is that to be discussed in an office far from reality ? -- Marc Dequènes (Duck) pgpjKqzPpPegn.pgp Description: PGP signature
Re: Thoughts on apps supporting multiple versions of python
On Sat, Apr 29, 2006 at 10:40:50PM -0600, Bruce Sass wrote: On Sat April 29 2006 16:01, Steve Langasek wrote: On Sat, Apr 29, 2006 at 06:28:32PM -0300, Gustavo Noronha Silva wrote: Also, to make python-gtk2 support more than one version, we could only achieve that by providing the extensions in a single package or building them on install time. Has anyone thought about this? Sure, this has been discussed heavily over the past 6 months. Unfortunately, there has been no visible progress on getting something specified and adopted for use in unstable. Any summaries, partial specs, top level descriptions, particularly good explanations of the stumbling blocks, etc., available for reading? https://wiki.ubuntu.com/PythonRoadmap http://wiki.debian.org/IRC/debian-tech/Logs/20051120-python-policy And... most of the debian-python archive for the month of January. I don't think I've seen any formally proposed policy write-ups yet. -- 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: Thoughts on apps supporting multiple versions of python
Le dimanche 30 avril 2006 à 01:48 -0700, Steve Langasek a écrit : Any summaries, partial specs, top level descriptions, particularly good explanations of the stumbling blocks, etc., available for reading? https://wiki.ubuntu.com/PythonRoadmap As far as I know, this roadmap has never been discussed on this list, and the only comments I've read about it is that it is definitely not reasonable if we want to have a working python2.4 in etch. -- .''`. 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
Thoughts on apps supporting multiple versions of python
Hello, Today I was playing with the idea of having gazpacho support multiple versions of Python. Nothing really forbids it, since it doesn't use anything that is specific to python2.4, for example. So I added gazpacho's module under python-support's control and made it not Depend on python = 2.3 and python 2.4. I have only: Depends: python-gtk2 (= 2.6.0), python-support That means I'll have whatever python version is the default one, since python-gtk2 is supposed to depend on python2.3-gtk2, and will switch to python2.4-gtk2. So I'm guaranteeing gazpacho will work, but I'll also have the following situation: gazpacho supports python2.4 but will only run with that version if python2.4-gtk2 is installed. Maybe we need a way of telling python-support that 'I can run with the following versions, but will only be able to do that if this package supports them'. Also, to make python-gtk2 support more than one version, we could only achieve that by providing the extensions in a single package or building them on install time. Has anyone thought about this? See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] http://people.debian.org/~kov/ signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: Thoughts on apps supporting multiple versions of python
Le samedi 29 avril 2006 à 18:28 -0300, Gustavo Noronha Silva a écrit : That means I'll have whatever python version is the default one, since python-gtk2 is supposed to depend on python2.3-gtk2, and will switch to python2.4-gtk2. So I'm guaranteeing gazpacho will work, but I'll also have the following situation: gazpacho supports python2.4 but will only run with that version if python2.4-gtk2 is installed. I don't understand how this is an issue for a package like gazpacho. This can become a problem if a module package python-foo uses python-support and requires python-gtk2. In this case, the package using python-foo has to depend python2.4-gtk2 even if it doesn't use gtk2 directly. Regards, -- .''`. 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: Thoughts on apps supporting multiple versions of python
On Sat April 29 2006 16:01, Steve Langasek wrote: On Sat, Apr 29, 2006 at 06:28:32PM -0300, Gustavo Noronha Silva wrote: Also, to make python-gtk2 support more than one version, we could only achieve that by providing the extensions in a single package or building them on install time. Has anyone thought about this? Sure, this has been discussed heavily over the past 6 months. Unfortunately, there has been no visible progress on getting something specified and adopted for use in unstable. Any summaries, partial specs, top level descriptions, particularly good explanations of the stumbling blocks, etc., available for reading? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
