8

I'm trying to install php-5.3 on Arch Linux, but bison is too new, so I built older version of bison from sources. And it appears it installs itself into /usr/local by default. (Is this some kind of convention?) So I'm now wondering if I can install more than one version of bison i.e., side-by-side with the default system one and the one I just installed. These kind of things are likely to be rarely needed. I'm just curious about it. Is this a hard thing to do? How should I go about it?

3 Answers 3

5

Some specific software can be configured with --program-suffix=-my-version-suffix. You may need to customize some of the other directories, but if you leave the --prefix to the default (/usr/local), that won't collide with the distro-packaged one in /usr.

In the general case however, the only distro that attempts to allow coinstallation of arbitrary versions is Nix, though Gentoo makes the attempt for more packages than most distros bother with (though for Bison it only allows one version at a time - at least it offers a choice though).

Do note, however, that if your source code breaks with newer versions of bison, that usually means a simple problem with your source code. Usually there is some %option (or --argument) that can fix it.

4
  • Can you tell more about how Nix deals with installing multiple versions of a package? And about Gentoo, attempting for more versions of packages I take it?
    – x-yuri
    Oct 11, 2014 at 7:01
  • 1
    @x-yuri Nix completely avoids installing anything under /usr, instead installing everything under /nix/some-unique-path-for-every-package/. So, you can install as many versions as you want, but you can only choose one to be symlinked into $PATH
    – o11c
    Oct 11, 2014 at 19:50
  • 1
    @x-yuri Gentoo is, compared to Nix, much more like normal distros, except that it does not ship binary packages, only scripts that can be used to build packages from source. However, since source packages are a lot cheaper to store, and since Gentoo uses upstream tarballs directly, it can afford to keep multiple versions of a package around for longer - for bison, 1.875d, 2.4.3, 2.7.1, and 3.0.2 - and if you want a different version, you can usually just copy the script and change the version number. gcc uses different SLOTs so you can install multiple versions side-by-side; bison doesn't.
    – o11c
    Oct 11, 2014 at 19:55
  • I had a hard time deciding which answer to choose. I suppose, modules package is most of the time overdoing it, so I will mark your answer as accepted. But Sebastian's answer is also good.
    – x-yuri
    Oct 12, 2014 at 19:41
4

One way to treat this problem consistently is using the modules package. It works by changing environmental variables (e.g. the paths to your binaries).

The Environment Modules package provides for the dynamic modification of a user's environment via modulefiles. Modules can be loaded and unloaded dynamically and atomically, in an clean fashion

e.g.

$ module load gcc/3.1.1 
$ which gcc 
/usr/local/gcc/3.1.1/linux/bin/gcc 

$ module switch gcc gcc/3.2.0 
$ which gcc 
/usr/local/gcc/3.2.0/linux/bin/gcc 

In your case, the bison version which comes first in your PATH environmental variable is selected. To inspect or change this variable manually for the current terminal, run

$ echo $PATH
 ....

priortize /opt/bin by _pre_pending it to the PATH:

$ export PATH="/opt/bin:$PATH"

or, append /opt/bin/ to the PATH (it is only selected if no equally named binary is found elsewhere in PATH)

$ export PATH="$PATH:/opt/bin"
2
  • But this package has nothing to do with installing programs? The program must either support --program-suffix option, or different versions must be installed with different --prefix'es, right?
    – x-yuri
    Oct 11, 2014 at 6:56
  • Correct. Almost all software distributed as source code support this. If they don't, you can always point to the compiled binaries (wirhout make install) with the PATH variable.
    – Sebastian
    Oct 11, 2014 at 10:08
0

Just to give a more updated answer:

Yes, this is definitely possible nowadays.
Dependency hell is a thing of the past, unless the distribution is too. :)

Arch doesn’t cut it though. You need a source-based distribution. As the dependencies would otherwise be hard-coded (for certain definitions of hard-coded), and both installations would point to the same libraries etc.
But when building from source, you can build it with different paths each time.

Gentoo has had a feature called “slotting” for this for a long time, that makes the whole thing trivial. The dependencies of a version of a package can be specified to be a certain “slot” of another package. A slot is a range of versions that don’t conflict with any other slot. (For most packages I’ve seen, any version can be its own slot. Especially for libraries. But sometimes a package can’t handle it because it itself depends on things of which there are only one. Or because it requires a bit of work from the package manager [e.g. to modify the installed config files on installation])

But I’m certain that any other full source distribution will have something similar.

Otherwise, a workaround is always, to set up the same build system that your distribution’s packages are built with by the maintainers, clone the required packages under a new name, and in there alter the build process to point to the different versions of the dependencies, and then just build that into a new non-source package like the package maintainers of your distribution would. (Frankly, I found Gentoo easier to install. :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .