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
