Re: python2.3/python2.4/python packages
On Mon, 2006-02-20 at 20:37 +0100, Matthias Klose wrote: > Donovan Baarda writes: [...] > > In the mean time, another alternative is to point your apt/sources.list > > at an Ubuntu archive and see if you can upgrade python from there... > > ugh, I would not try that ... you cannot differentiate between python > and non-python things ... I never said it would be easy :-) You can kind of do this using a combination of /etc/apt/preferences and judicious use of aptitude. Cunning preferences-fu can favour most packages in Debian, except python* packages from Ubuntu. You can then use aptitude to fine-tune pick and choose which versions you want to install. This will probably reveal nasty dependencies of the python packages on bucketloads of other Ubuntu libs etc, but you might get lucky... -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.3/python2.4/python packages
Donovan Baarda writes: > On Thu, 2006-02-09 at 17:09 -0500, Derrick Hudson wrote: > > On Thu, Feb 09, 2006 at 10:57:50PM +0100, Pavel Å imerda wrote: > [...] > > At this point we really just need to move the default to 2.4. 2.4 has > > been available for a rather long time now. > > > > -D > > > > PS I am aware of several factors (including C++ and other > > transitions) that resulted in not starting a python transition > > sooner. Regardless, 2.4 isn't "new" anymore and ought to be the > > default. I look forward to seeing this happen :-). yes. As pointed out, there have been problems with both python-central/python-support, regarding the handling of dependencies. I'm going to upload a new python package which handles recompilation of packages with "private" modules (outside the default sys.path). Then we can start the transition. Still evaluating an extension of python-support, if we can just drop the dependency of pure library packages to the interpreter at all. > Note that Ubuntu transitioned to python2.4 as the default some time ago > (and they have almost complete support for python's all the way back to > python2.1) ... given the appearance of python-minimal I think Debian is > leveraging off their work and will hopefully get there soon. > > In the mean time, another alternative is to point your apt/sources.list > at an Ubuntu archive and see if you can upgrade python from there... ugh, I would not try that ... you cannot differentiate between python and non-python things ... Matthias
Re: python2.3/python2.4/python packages
On Thu, 2006-02-09 at 17:09 -0500, Derrick Hudson wrote: > On Thu, Feb 09, 2006 at 10:57:50PM +0100, Pavel Šimerda wrote: [...] > At this point we really just need to move the default to 2.4. 2.4 has > been available for a rather long time now. > > -D > > PS I am aware of several factors (including C++ and other > transitions) that resulted in not starting a python transition > sooner. Regardless, 2.4 isn't "new" anymore and ought to be the > default. I look forward to seeing this happen :-). Note that Ubuntu transitioned to python2.4 as the default some time ago (and they have almost complete support for python's all the way back to python2.1) ... given the appearance of python-minimal I think Debian is leveraging off their work and will hopefully get there soon. In the mean time, another alternative is to point your apt/sources.list at an Ubuntu archive and see if you can upgrade python from there... -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.3/python2.4/python packages
> Take, for example, sharpmusique. I want to be able to browse the > iTMS. Since I don't develop with C# or Mono/.NET I don't know > anything about the different versions of each and I really don't care. > I just want the application to work. The package depends on a version > of mono that works, and I'm a happy user. I was talking about libraries... sorry for not being clear enough. And... I don't know about non-library packages called python*-package (maybe there are some). I thought application packages are named as any non-python program. > Likewise you don't ask for different packages of kmail (or python), > one built with each version of gcc. If it works, you don't care :-). See above. > However, if the software is a library and the user of the software is > a developer, then the version of python may matter and you may have > reasonable use cases for having a 2.3 and a 2.4 version. I would be > highly skeptical if you also claimed that you need a 2.2, 2.1 and/or > 2.0 version. What I want is... the latest version, and maybe those versions that are needed to run some applications. I thing for debian it's 2.4 and 2.3, so you don't have to [be sceptical]. > A lot of libraries are provided this way. I don't think any > applications are. Some libraries aren't, because the maintainer > decided the return on investment for supporting a non-default version > of python is too low for the cost involved. The same misunderstanding... library packages, of course > Ideally there would be exactly one version of python, and exactly one > package for each of the extension modules and applications using > python. This is not really practical because python improves and new > versions become available. Developers (users of debian) will need > multiple versions of python to ensure that the products they develop > are compatible with the range of python versions they expect users of > their product will use. The compromise is that debian provides a > python package marked as the 'default' version. This is the 'exactly > one' version in the ideal scenario. In practice, other non-default > versions of python are provided as well. Individually the maintainers > of each package that uses python can choose to support only the > default python, or support the default and any other optional versions > they choose to support. An exception is if the default python is to > obsolete and their package only works with a newer version. That's what I would expect... but a python user (I mean programming language user / developer) must code for python 2.3 now, if he uses libraries such as wxWidgets or kid. Even if those libraries run perfectly on python 2.4. Python improves and developers want to code for the current version, not the old one, in my opinion. And, btw... the scheme you are describing would work ONLY if all libraries were named python-package and default version in a metapackage. Maintainer cannot choose the dependency (working with several versions of python installed) for an application using wxWidgets... because there is no python 2.3 version and no python2.4 version He has to use the default version allways. So if you make (or package) wx applications there is only one version of python and all python-library packages are of no use to you. > As I mentioned before, the real problem is that etch's default python > is still 2.3, which is now quite obsolete. If the transition to > making 2.4 the default were complete you would have nothing to > complain about :-). That's right But I'd like at least one way working... alright, there is one way working setup.py ;-) Pavel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.3/python2.4/python packages
On Sat, Feb 11, 2006 at 01:49:16PM +0100, Pavel Šimerda wrote: | On 2006-02-10 18:12, Josselin Mouette wrote: | > Le vendredi 10 février 2006 à 16:46 +0100, Pavel Šimerda a écrit : | > > > For a module that has few or zero reverse dependencies, there should be | > > > one single package, named python-foo, containing the module for the | > > > default python version. Anything else is just cluttering the archive. | > > | > > You think it's better to force users to a specific version... I thought | > > MOST of the packages were in two binary versions (2.3 and 2.4) with one | > > dummy package dependant on the default. It seems you don't like peple | > > who'd like to make their own packages do you? | > | > I don't like people who like to provide several packages just for the | > pleasure of providing several packages. | Not an anwer at all. I mean someone would like to package his program or tool | and make it dependant on kid0.8 templates and python2.4. | | So he sets the dependency: kid (>= 0.8) and python2.4 currently, kid is | installed in python 2.3 and the dependency just fails. I hate broken | dependencies ;-) as much as any user does Indeed. You can't mix a non-default version of python with a package that only supports the default version of python. [...] | In these cases I don't even need python-* type of packages... because I know | which versions I support in my programs. Your program "should" use the default version of python. The python-* meta packages exist to make transitions easier. When a library 'foo' supports both the current/previous python and the current/next python, the python-foo package is trivial to change so that all dependents (who are using the default version, not a specific version) will use the new default. | And because i was looking at python package called kid... expected python-kid | but that was just 'kid' If it is a library, not an application, then I would consider that a bug in the packaging. If kid is a library and it works with python 2.4 and if you need to use python 2.4 for your application, then you'll need to do one (or more) of the following: + kindly ask the maintainer to provide a binary package for python 2.4 (in addition to the binary package for 2.3) + create your own unofficial python2.4-kid package + install kid locally outside of the package management system + wait for the default python to be updated | And also confused by the fact that python2.3 and python2.4 families | are not at all complete as I expected. Per the Python Policy, maintainers are allowed to support only the default version of python. Thus I would expect to have more libraries available for python 2.3 (the current default) than for 2.4. One last time, the solution is to update the default version of python :-). (for reference, 2.4 was released as stable by upstream 14 months ago) HTH, -D -- If your life is a hard drive, Christ can be your backup. www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: python2.3/python2.4/python packages
On Fri, Feb 10, 2006 at 04:46:58PM +0100, Pavel Šimerda wrote: | On 2006-02-10 09:05, Josselin Mouette wrote: | > Le jeudi 09 février 2006 à 22:57 +0100, Pavel Šimerda a écrit : | > > At first look I thought python packages in debian are called | > > python2.3-packagename and python2.4-packagename. And that there's a | > > metapackage python-packagename that requires the 2.3 version installed. | > > | > > Now I see this is not so with all packages and it is hard to see | > > which packages are present in python2.3 and missing in python2.4. | > | > Of course this is not the case for all packages. We don't need 4 binary | > packages for each python-foobar module. | > | > For a module that has few or zero reverse dependencies, there should be | > one single package, named python-foo, containing the module for the | > default python version. Anything else is just cluttering the archive. | | You think it's better to force users to a specific version... Yes, for an application. For a library, maybe. Take, for example, sharpmusique. I want to be able to browse the iTMS. Since I don't develop with C# or Mono/.NET I don't know anything about the different versions of each and I really don't care. I just want the application to work. The package depends on a version of mono that works, and I'm a happy user. Likewise you don't ask for different packages of kmail (or python), one built with each version of gcc. If it works, you don't care :-). However, if the software is a library and the user of the software is a developer, then the version of python may matter and you may have reasonable use cases for having a 2.3 and a 2.4 version. I would be highly skeptical if you also claimed that you need a 2.2, 2.1 and/or 2.0 version. | I thought MOST of the packages were in two binary versions (2.3 and | 2.4) with one dummy package dependant on the default. A lot of libraries are provided this way. I don't think any applications are. Some libraries aren't, because the maintainer decided the return on investment for supporting a non-default version of python is too low for the cost involved. Ideally there would be exactly one version of python, and exactly one package for each of the extension modules and applications using python. This is not really practical because python improves and new versions become available. Developers (users of debian) will need multiple versions of python to ensure that the products they develop are compatible with the range of python versions they expect users of their product will use. The compromise is that debian provides a python package marked as the 'default' version. This is the 'exactly one' version in the ideal scenario. In practice, other non-default versions of python are provided as well. Individually the maintainers of each package that uses python can choose to support only the default python, or support the default and any other optional versions they choose to support. An exception is if the default python is to obsolete and their package only works with a newer version. As I mentioned before, the real problem is that etch's default python is still 2.3, which is now quite obsolete. If the transition to making 2.4 the default were complete you would have nothing to complain about :-). -D -- "Open Source Software - Sometimes you get more than you paid for..." www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: python2.3/python2.4/python packages
On 2006-02-10 18:12, Josselin Mouette wrote: > Le vendredi 10 février 2006 à 16:46 +0100, Pavel Šimerda a écrit : > > > For a module that has few or zero reverse dependencies, there should be > > > one single package, named python-foo, containing the module for the > > > default python version. Anything else is just cluttering the archive. > > > > You think it's better to force users to a specific version... I thought > > MOST of the packages were in two binary versions (2.3 and 2.4) with one > > dummy package dependant on the default. It seems you don't like peple > > who'd like to make their own packages do you? > > I don't like people who like to provide several packages just for the > pleasure of providing several packages. Not an anwer at all. I mean someone would like to package his program or tool and make it dependant on kid0.8 templates and python2.4. So he sets the dependency: kid (>= 0.8) and python2.4 currently, kid is installed in python 2.3 and the dependency just fails. I hate broken dependencies ;-) as much as any user does When you need python2.4 (not only 2.3) with cherrypy2.1 (not only 2.0), all works great. You set it dependent on python2.4-cherrypy2.1 which depends on python2.4, and is installed in its structure. In these cases I don't even need python-* type of packages... because I know which versions I support in my programs. I quite like meta-packages, that make dependencies work better. I allways thought this is a strong point of APT. > > > I don't mean it bad... I already switched to setup.py installation > > instead of apt so I can use python2.4 now. I'm just trying to make things > > better for other users. > > You should think of comparing the value added by providing several > packages and the cost of cluttering the archive and confusing users. Ask > yourself whether this is worth the complication. I am thinking about it... as I was one of the confused users - confused that python-* is sometimes a metapackage and sometimes a real package. (Not from the total number of packages related to python.) And because i was looking at python package called kid... expected python-kid but that was just 'kid'... searched for 2.4 version but there is none And also confused by the fact that python2.3 and python2.4 families are not at all complete as I expected.
Re: python2.3/python2.4/python packages
Le vendredi 10 février 2006 à 16:46 +0100, Pavel Šimerda a écrit : > > For a module that has few or zero reverse dependencies, there should be > > one single package, named python-foo, containing the module for the > > default python version. Anything else is just cluttering the archive. > > You think it's better to force users to a specific version... I thought MOST > of the packages were in two binary versions (2.3 and 2.4) with one dummy > package dependant on the default. It seems you don't like peple who'd like to > make their own packages do you? I don't like people who like to provide several packages just for the pleasure of providing several packages. > I don't mean it bad... I already switched to setup.py installation instead of > apt so I can use python2.4 now. I'm just trying to make things better for > other users. You should think of comparing the value added by providing several packages and the cost of cluttering the archive and confusing users. Ask yourself whether this is worth the complication. -- .''`. 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: python2.3/python2.4/python packages
> That depends ... if you need some 3rd party package/module that debian > built only for 2.3 then yes, but if all the package/modules that you > need have python2.4 builds in debian then you can use 2.4. this is the case with wxWidgets and kid > See the Python Policy for the various circumstances for each > arrangement. Hmm, I've just read it. It really allows python-something to be package 'something' for the default version of python. Still wouldn't be better to name the packages according to python version from the start? For easier and more reliable dependency management? And... I would expect I was not the only user to list all python 2.3/2.4 packages to see what apt repository offers (and at the same time, what you can do with python) - examining python2.3-* packages one by one. > | would it be so difficult to rename the packages according to this scheme? > > For some it isn't, for some it is. For some it is difficult? Why? Dependencies are maintained, apt-get install still works without changing package name... but it gives the programmers a bit more freedom. > > [...] > > | Then there's also package python-wxgtk2.6: > | * as it's actually python2.3 version, I would rename it > | python2.3-wxgtk2.6 * metapackage python-wxgtk2.6 depending on > | python2.3-wxgtk2.6 > | * what about python-wxgtk (?) > | (* again, we would be prepared for python2.4-wxgtk2.6) > > I haven't built wx, but I can imagine that it would not be trivial. > The maintainer chose to only build one variation, and so it is only > for the default version (python 2.3) and doesn't specify that version > in the package name. If you were to simultaneously build a python 2.4 > version, then that naming would be appropriate. Hmm this looks like saying... I'll name it python-* because we're not going to make this package for 2.4. > At this point we really just need to move the default to 2.4. 2.4 has > been available for a rather long time now. Yes, I agree, couldn't this be the first step? To have all packages working as python2.4-* and finally just modify python2.3 and python2.4... and then switch at once, changing only the dependencies. > PS I am aware of several factors (including C++ and other > transitions) that resulted in not starting a python transition > sooner. Regardless, 2.4 isn't "new" anymore and ought to be the > default. I look forward to seeing this happen :-). Ok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.3/python2.4/python packages
On 2006-02-10 09:05, Josselin Mouette wrote: > Le jeudi 09 février 2006 à 22:57 +0100, Pavel Šimerda a écrit : > > At first look I thought python packages in debian are called > > python2.3-packagename and python2.4-packagename. And that there's a > > metapackage python-packagename that requires the 2.3 version installed. > > > > Now I see this is not so with all packages and it is hard to see > > which packages are present in python2.3 and missing in python2.4. > > Of course this is not the case for all packages. We don't need 4 binary > packages for each python-foobar module. > > For a module that has few or zero reverse dependencies, there should be > one single package, named python-foo, containing the module for the > default python version. Anything else is just cluttering the archive. You think it's better to force users to a specific version... I thought MOST of the packages were in two binary versions (2.3 and 2.4) with one dummy package dependant on the default. It seems you don't like peple who'd like to make their own packages do you? I don't mean it bad... I already switched to setup.py installation instead of apt so I can use python2.4 now. I'm just trying to make things better for other users. Pavel
Re: python2.3/python2.4/python packages
Le jeudi 09 février 2006 à 22:57 +0100, Pavel Šimerda a écrit : > At first look I thought python packages in debian are called > python2.3-packagename and python2.4-packagename. And that there's a > metapackage python-packagename that requires the 2.3 version installed. > > Now I see this is not so with all packages and it is hard to see which > packages are present in python2.3 and missing in python2.4. Of course this is not the case for all packages. We don't need 4 binary packages for each python-foobar module. For a module that has few or zero reverse dependencies, there should be one single package, named python-foo, containing the module for the default python version. Anything else is just cluttering the archive. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: python2.3/python2.4/python packages
On Thu, Feb 09, 2006 at 10:57:50PM +0100, Pavel Šimerda wrote: | So it means debian's default version of python is 2.3 so everybody will | use python 2.3 if he wants things working? That depends ... if you need some 3rd party package/module that debian built only for 2.3 then yes, but if all the package/modules that you need have python2.4 builds in debian then you can use 2.4. | At first look I thought python packages in debian are called | python2.3-packagename and python2.4-packagename. And that there's a | metapackage python-packagename that requires the 2.3 version installed. | | Now I see this is not so with all packages and it is hard to see which | packages are present in python2.3 and missing in python2.4. See the Python Policy for the various circumstances for each arrangement. | would it be so difficult to rename the packages according to this scheme? For some it isn't, for some it is. [...] | Then there's also package python-wxgtk2.6: | * as it's actually python2.3 version, I would rename it python2.3-wxgtk2.6 | * metapackage python-wxgtk2.6 depending on python2.3-wxgtk2.6 | * what about python-wxgtk (?) | (* again, we would be prepared for python2.4-wxgtk2.6) I haven't built wx, but I can imagine that it would not be trivial. The maintainer chose to only build one variation, and so it is only for the default version (python 2.3) and doesn't specify that version in the package name. If you were to simultaneously build a python 2.4 version, then that naming would be appropriate. At this point we really just need to move the default to 2.4. 2.4 has been available for a rather long time now. -D PS I am aware of several factors (including C++ and other transitions) that resulted in not starting a python transition sooner. Regardless, 2.4 isn't "new" anymore and ought to be the default. I look forward to seeing this happen :-). -- >Linux is not user-friendly. It -is- user-friendly. It is not ignorant-friendly and idiot-friendly. (Seen somewhere on the net.) www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
python2.3/python2.4/python packages
On 2006-02-01 21:20, Bob Tanner wrote: > Pavel ?imerda wrote: > > Hi people > > I debian/testing there's a deb package called just 'kid'. It's a very > > nice templating system for python. > > > > Debian's package 'kid' is for python2.3... so I'd maybe prefer calling it > > python2.3-kid. > > > > And there's no python2.4 version of this package... > > Although it's easy to install it using python2.4 setup.py install... it > > doesn't install 2.4's scripts properly. > > > > Pavel > > Officially, wait for DD to push it > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338276 So it means debian's default version of python is 2.3 so everybody will use python 2.3 if he wants things working? At first look I thought python packages in debian are called python2.3-packagename and python2.4-packagename. And that there's a metapackage python-packagename that requires the 2.3 version installed. Now I see this is not so with all packages and it is hard to see which packages are present in python2.3 and missing in python2.4. would it be so difficult to rename the packages according to this scheme? Examples: I'll return to the package kid... what I would expect is: * the package would be python2.3-kid instead of just 'kid' * meta package python-kid would depend on python2.3-kid * meta package kid would depend on python-kid (for backwards compatibility) (* later there could be a new package called python2.4-kid) Then there's also package python-wxgtk2.6: * as it's actually python2.3 version, I would rename it python2.3-wxgtk2.6 * metapackage python-wxgtk2.6 depending on python2.3-wxgtk2.6 * what about python-wxgtk (?) (* again, we would be prepared for python2.4-wxgtk2.6) So... what do debian folks think about it? Pavel > Unofficially > > deb ftp://ftp.real-time.com/linux/real-time-debpool sid custom main > deb-src ftp://ftp.real-time.com/linux/real-time-debpool sid custom main I am now running unstable... > > -- > Bob Tanner <[EMAIL PROTECTED]> | Phone : (952)943-8700 > http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
