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: dman@dman13.dyndns.org
Attachment:
signature.asc
Description: Digital signature