Jörn Clausen <joernc%googlemail.com@localhost> writes: > On Fri, Mar 2, 2012 at 12:49 AM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote: >> [non-ASCII characters that I didn't send removed from the quote] >> package with no suffix is the latest stable, and suffixes are old >> versions >> >> seems reasonable as well. And after adding that, we have arrived, more >> or less, at the current state, so I'm not sure what you want to change. > > That's not true for python, there is no package without a version > number. Agreed; I meant that we have a mix of always-suffixed packges and some where the current version is not suffixed. > Which is, in a way, the problem one of my users had, when I > switch from Python 2.5 to 2.6 a few weeks ago. As all packages are > versioned, the name of the interpreter changed from python25 to > python26. This is a completely separate issue from the package name. The emacs22 and emacs packages both install emacs, and one can have one or the other. python, on the other hand, can be installed in parallel. This is necessary because python upstream has poor inter-version compatibility, and you can't just take code that works on 2.5 and run it on 2.6. Because so many things depends on python, the only sane thing to do is to have parallel-installable python versions, with parallel-installable modules to go with. > I don't know if his software has problems per se to change > from 2.5 to 2.6, but at least the changed name of the interpreter > broke his application. Having a consistent name for a binary would be > IMHO a nice side effect of having a default package without a version > number. I see your point about a name without a suffix, but with python we have to have multiple versions installed. Once you have can have multiple versions, using programs have to find the interpreter and see if it is acceptable, and also find if the required modules are installed, etc. If python were one day 2.5, and then because 2.6, then programs using it would suddenly see a different set of modules. That said, people can certainly symlink python to python2.6 if that convenience outweighs the variable binding risk. Your user's program should probably find python via configure and subsitute the interpreter path. In my view, that's just how it is when one uses a family of languages rather than a language. > The Java packages are another example, where the name of the > "interpreter" changes with every package. Some mechanism to say "this > is the (or even better: 'my') default package, and it provides > /usr/pkg/bin/python, /usr/pkg/bin/java, etc." would provide another > aspect of stability. At least as long as the application is compatible > with the different versions of Python/Java/etc, of course. That's the problem. We have arrived at the current situation precisely because python and java are not names of languages, but families of related languages. python 2.5, python 2.6, openjdk X, etc. are names of languages. When we upgraded gcc, it was replaced, not used in parallel, and while a lot of things needed fixing, it was because the old code was wrong, not because the language specifications implemented by the two compilers are different. Sorry if this sounds like a rant - but I think the underlying causes of the pain your user is having are real and due to python changing the language in incompatible ways.
Attachment:
pgpAh5Fxxhgvr.pgp
Description: PGP signature