Where should I put software I compile myself?

Question

I need to compile some software on my Fedora machine. Where's the best place to put it so not to interfere with the packaged software?

Answer 1

Rule of thumb, at least on Debian-flavoured systems:

/usr/local for stuff which is "systemwide" - i.e. /usr/local tends to be in a distro's default $PATH, and follows a standard UNIX directory hierarchy with /usr/local/bin, /usr/local/lib, etc.

/opt for stuff you don't trust to make systemwide, with per-app prefixes - i.e. /opt/firefox-3.6.8, /opt/mono-2.6.7, and so on. Stuff in here requires more careful management, but is also less likely to break your system - and is easier to remove since you just delete the folder and it's gone.

Answer 2

If you really don't want it to interfere at all, don't put it anywhere in your $PATH.

If you want it in $PATH, at least make sure not to install to /usr/local...I've found that a lot of software looks there even if it's installed by the distro into /usr.

My favorite way to install custom-compiled software is in my home directory. That way you don't have to use sudo for anything, and it's very nicely separated from the rest of your system. For example:

mkdir ~/stage
./configure --prefix=/home/username/stage && make && make install

And if you want to, you can then add /home/username/stage/bin to your $PATH.

Answer 3

Most of the time, I like to place my own compiled stuff in /opt. It's sort of a pseudo-standard place. You can also consider /usr/local, but I prefer to keep my stuff 100% isolated.

Answer 4

FHS says to put it in /usr/local where distributions shouldn't be touching it. /usr/local/bin for the binaries /usr/local/src for the source and /usr/local/lib for libraries. See the FHS spec for more info

Answer 5

/usr/local/src

What I do is extract the source in this directory. It will create a path like

/usr/local/src/postgresql-8.3.7

I will create a symbolic link to this

/usr/local/src # ln -s postgresql-8.3.7 postgresql

Do all your building in /usr/local/src/postgresql

Doing things this way helps when you need to pop between versions and documents what version you are using.

Answer 6

If there is possibility - I'd suggest compiling your software and then creating FC package (I believe it's using yum to install software packages). Then you can install that package of your own compiled software and remove it without messing up the whole system.

Answer 7

If you want to able to easily install and remove several applications you've built yourself, you can use Stow as a simple package manager.

Answer 8

This reminds me, I need to use checkinstall more often! That way I just do the usual

 ./configure
 make

followed by

 sudo checkinstall

to create a .deb file...

Answer 9

Per the FHS, /usr/local/ is used for applications compiled from source, while /opt/ is used for 3rd party applications not supported by your operating system vendor.

Answer 10

Two things I'd recommend:

System wide: use stow and install under /usr/local/stow/package-version. Then you can easily switch between version.

In my home, or if I don't have /usr/local write permissions, I personally install programs under ~/.local, which is hinted by XDG standard.

You can also use stow locally, although I never did :)

Answer 11

I have a little different setup than most people because I do a lot of development. I have a /home/jackson/bin/ directory that I install stuff into and I've edited my .bashrc adding this:

export PATH=/home/jackson/bin/bin::$PATH
export LD_LIBRARY_PATH=/home/jackson/bin/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/home/jackson/bin/lib/pkgconfig:$PKG_CONFIG_PATH

I wouldn't do this for everything, but its nice during development.

Answer 12

It is actually not that hard to create deb's or rpm's from a source tarball. That way, you can use the facilities of your distro's package manager to keep your system clean. This is what I do, most of the time: just create a little rpm.

Answer 13

There's always the option to "put it where it belongs" but write a simple rpm, first.

Answer 14

if you are compiling an application you can add its executables path in you PATH env variable. this will not impact other users.

Answer 15

If you want your application to be available for all users on the system and you have the necessary permissions, use /opt. If you want the application to be available only for you (and root), use /home/username

Answer 16

The easiest way of doing this is to grab the source package (.src.rpm for RPMites), unpack it, hack the new source/configuration/whatever into it, change the version appropiately and build. Installing this makes your package manager aware of the new package, allows to consider it for dependencies and uninstall/update.

This is a chore the first time around, but if a new version (or some critical patch) comes out, it is then simpler to update. Another benefit is that you can create your own repository with local software, to be shared e.g. by the machines in a lab.