150

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?

Improve this question
1

16 Answers 16

Reset to default
104

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

  • /usr/local for stuff which is "system-wide"—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 system-wide, 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.

Improve this answer
3
  • interestingly, many programs/appplications automatically suggest to install to /opt if you do sudo install.
    – HongboZhu
    Sep 10, 2018 at 8:28
  • I would also recommend puting your source code in a subdirectory ie /usr/local/src. Cf unix.stackexchange.com/a/362784/78577 and refspecs.linuxfoundation.org/FHS_3.0/…
    – 4wk_
    Mar 25, 2021 at 15:24
  • 1
    Please, please stop using this extremely bad system. Just put it in your user dir, in something with a normal, sensible name like ~/apps and then either symlink binaries into a $PATHed directory or add them as aliases to your shell config. The world of computers has enough dumb complexity as it is.
    – iono
    Jul 29, 2022 at 17:35
53

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.

Improve this answer
5
  • 2
    Definitely, using your home directory is the best option. IMO.
    – Alex Bitek
    Aug 10, 2010 at 20:24
  • 1
    +1 Agreed. I like ~/sbin for bash/ruby/python scripts, and ~/opt/... for compiled installs, with aliases in ~/bin.
    – Kris
    Aug 10, 2010 at 20:59
  • 4
    +1 for using your home directory as it makes things simpler; -1 for the suggestion to avoid $PATH -- there are actually directories there "reserved for local installs" according to the standards (e.g., /usr/local).
    – Riccardo Murri
    Aug 11, 2010 at 8:34
  • 1
    My suggestion to avoid /usr/local was based on the original poster's (somewhat vague) desire to not interfere with packaged software. Since there is plenty of packaged software that will "help" by looking in /usr/local or in $PATH, I figured that qualifies as interfering. But it really depends on a person's individual needs and goals. /usr/local can be a perfectly fine choice in many situations.
    – Sandy
    Aug 11, 2010 at 13:05
  • no one noticed the completely misunderstanding of the letter "s" in comment #2. that should be deleted
    – Northstrider
    Mar 5, 2017 at 21:18
24

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

Improve this answer
2
  • What about configuration? Say I installed MySQL without using the package manager, should I still use /etc/mysql for the configuration?
    – Hubro
    Jul 1, 2015 at 4:38
  • I just noticed there is a /usr/local/etc folder by default, I guess I should use that... :-)
    – Hubro
    Jul 1, 2015 at 4:40
10

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.

Improve this answer
7
  • 2
    distro's tend to put quite a few things in /opt (usually proprietary packages) /opt doesn't say that the distro can't touch it. however it does say that about /usr/local
    – xenoterracide
    Aug 10, 2010 at 20:04
  • 2
    I've never seen a distro put stuff in /opt, however I've seen many times where /usr/local is littered with junk that does come from the distro
    – Scott Arrington
    Aug 10, 2010 at 20:07
  • distro's I use like to put java in /opt I've seen acrobat reader in there too. if they are putting stuff in /usr/local they are ignore FHS which say it needs to be safe from being overwritten in system updates.
    – xenoterracide
    Aug 10, 2010 at 20:10
  • To each their own, I guess. FHS is nice, but I think it gets ignored sometimes.
    – Scott Arrington
    Aug 10, 2010 at 20:12
  • The only stuff I've ever seen distro packages place in /usr/local was directory hierarchies that paralleled those in the standard tree, and maybe index files for things like TeX.
    – Phil Miller
    Aug 10, 2010 at 20:14
10

Put them to /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

Then I create a symbolic link to it:

/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.

Improve this answer
1
  • 1
    +1 for stating your rationale and how the OP may apply it, including versioning.
    – samt
    Aug 10, 2010 at 23:07
7

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.

Improve this answer
5

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.

Improve this answer
5

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.

Improve this answer
4

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 :)

Improve this answer
3

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.

Improve this answer
3

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.

Improve this answer
2

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

Improve this answer
3
  • I wonder why the down votes? +1 to kind of "balance off"
    – phunehehe
    Aug 11, 2010 at 7:04
  • I am also wondering why :-). I have used same solution for using cscope where i don't have install permissions.
    – Hemant
    Aug 11, 2010 at 7:14
  • 1
    @phunehehe Probably because it doesn't even attempt to answer the question. The question asks where to place software. This answer gives a tip on what you could do after you've placed it somewhere. It could be improved by giving some suggestions on which folders to use.
    – JBentley
    Feb 15, 2019 at 17:31
2

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

Improve this answer
1

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

Improve this answer
0

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.

Improve this answer
0

Write an RPM, it is not difficult, has guidelines on where to put things and makes uninstalling a snap.

If you do this, install files under /usr and not under /usr/local, like all other files that come through the packaging system.

Improve this answer

You must log in to answer this question.

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