Installing incompatible major versions of packages alongside each other

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Ludo,

> In the former command-line package specification syntax, which is still
> supported but deprecated, “ptpython-2” was taken to mean “version 2 of
> package ‘ptpython’”.  Because of this, you cannot refer to this
> “ptpython-2” package from the command-line (except with -e).
> 
> The solution is to call it differently, like “ptpython2”.

Hmm, it doesn't seem as if Guix Python itself uses that policy. Python 2.7 is called "python-2.7" (note: dash)

I'm used to semantic version numbers.

Usually, the major version is increased because something major is incompatible.

For example Python 3 changed "print" from prefix operator to function. So almost no program that uses Python 2 "print" will work in Python 3. (they also changed the default string representation and lots of other things)

Therefore, it makes sense (and is common) to install and use both Python 2 and Python 3.

For pypython, too, you'd have it be able to use a Python 2 and a Python 3 interpreter.

I think this is a general rule. However, some packages and/or developers use non-standard version numbers. Therefore it would be good to be able to override this rule as a packager.

Therefore, Gentoo packages have something called a "SLOT". It's an extra number in the package spec which specifies which slot of the base package you want to fill in the installation.

For example if you install

  dev-lang/python-3.4.3

it will install it in slot 3 [the 3 is in the package file which you can't see here; it says SLOT=3 in there] (and replace the thing in slot 3 if necessary)

and if you install

  dev-lang/python-2.7.3

it will install it in slot 2 [it says so in the package spec file] (and replace the thing in slot 2 if necessary).

If you uninstall

  dev-lang/python

it will remove both.

If you uninstall

  dev-lang/python-3.4.3

it will just remove this one.

For a completely different take, Debian just adds this kind of slot number to the package basename - as you suggest I do.

There, it would just be "python2.6" for Python 2.6 and "python3" for Python 3.

Which mechanism does Guix use? Which should it use?

The guix.texi manual seems to advocate using names like "python-2" - which I seem to have the most problems in practise with. For example right now I can't install icedtea-7: "guix package: error: icedtea: package not found for version 7"