1

The LTS repo is pretty good, but for some reason I prefer the "build from source" method for some programs. One reason is that I get the preferred version (PHP on LTS is on 5.3, whereas I can compile 5.4 from source). Similar is the case for nginx, node.js, etc.

Now I would like to know, why all tutorials insist on installing the programs to the "root-owned" folders such as /opt, /srv, or /usr/local. I find it much easier to install it in my home folder such as: /home/prahlad/programs/PHP-5.4

One advantage is that I don't need to use sudo to install these programs. Second and a related advantage is security concern. What if (suppose) any of these sources happen to contain malware (though less probable on linux)? Isn't denying them root privilege a good thing to do?

I would like to know one example where it becomes necessary for a program to get installed in a root-owned folder?

  • 2
    "why all tutorials insist on installing the programs to the "root-owned" folders" Do they all really do that? In any case, it's just the common practice, since most people will want the software available system wide. You are not bound by that, and certainly it is simple enough to build from source without privileges and set PREFIX=$HOME. – goldilocks Jun 24 '14 at 18:34
  • @goldilocks - The tutorials may not specifically do that, but all examples involve /opt or /usr/local. I didn't see any with the ~ example, hence was concerned whether my approach is correct or not. – Prahlad Yeri Jun 24 '14 at 18:36
  • 1
    There is this thing called FHS. Learn it, live it, love it. – Faheem Mitha Jun 24 '14 at 19:29
2

The guides tell you to install in /usr/local/ or /opt etc so that others may use them.

If you install in your home directory then only you will have access to them. If you're just compiling for yourself, then this is fine.

  • Okay. Is that all, does it make any performance difference? I asked this since I could not find any example where a package is installed in the home directory, so my approach is correct or not (I'm a single user). – Prahlad Yeri Jun 24 '14 at 18:40
  • 2
    I can't see it making any difference to performance. I think all the examples you see on the Internet are for sysadmins and explain how to install the packages system wide. Remember that if you weren't the sysadmin for your system then the only place you could compile/install is your home directory - you wouldn't have write access to /usr/local or /opt etc. – garethTheRed Jun 24 '14 at 18:47
1

This is not a hard and fast rule, but stuff that defaults to /opt is usually self-contained, and may require that you copy or symlink executables into an executable path, or add an internal folder to $PATH. That's simple enough to figure out if you prefer to put it somewhere else and use a $HOME/bin.

Source built stuff that defaults to /usr/local, however, may also be installing shared libraries and man pages. If you want to put it somewhere else, usually you first export the PREFIX variable (or supply it on the command line with make); ./configure --help may confirm and explain this.

In that case, you need a bit of a directory hierarchy in the path you want to use. It should look like:

bin/
lib/
include/
share/
    man/
        man1/

There are further manX directories you can create (have a look at /usr/share/man for a model) although installers may create those if they don't exist. You'll then want the following in, e.g., ~/.profile:

export PATH=~/bin:$PATH
export LD_LIBRARY_PATH=~/lib:$LD_LIBRARY_PATH
export MANPATH=~/share/man:$MANPATH

If the package does use shared libraries, the LD_LIBRARY_PATH is crucial or the executables won't be able to link to them. MANPATH may not work on all systems and is not strictly necessary anyway -- if man foobar fails, you'll probably know where to look for it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.