14

Is there a standard location in Linux for holding source files for example OpenSSL. I am building Nginx from source with non default version of OpenSSL. I need to download and untar OpenSSL and I did it in home directory. Now, I wonder is there a standard location in Linux maybe /opt ?

  • 1
    As terdon wrote /usr/src is the standard location, and you may here find directories for the kernel source (/usr/src/linux linked to /usr/src/linux-version) and for example X11. Source-code for packages installed locally (/usr/local) fits better in /usr/local/src. If you want to build packages "manually" yourself, creating a src-directory in your homedir is probably a good idea... Remember you should not download, unpack or build as root - only install as! If you build deb/rpm-packages, temporary build directories (eg. under /var/tmp) are typically used instead. TBC – Baard Kopperud May 2 '17 at 22:34
  • If you build and install a package - or create a package (rpm/dem) - yourself, you usually don't need the source-code anymore after it's installed. The reason why you may have the source-code for some packages - like the kernel or X11 - under /usr/src (or /usr/local/src if it was created locally), is mostly because you may need them if you're building (or writing) some software package yourself (eg. some obscure header-files from the kernel, matching your actual system set-up). (Of course, you'll need it if you want to build your own kernel too...) But this applies to few packages. – Baard Kopperud May 2 '17 at 22:40
19

Whenever you ask yourself something like this, check out the Filesystem Hierarchy Standard (FHS).There, you will find the following entry:

usr/src : Source code (optional)

Purpose

Source code may be placed in this subdirectory, only for reference purposes

So you can put your source files in subdirectories of /usr/src. That said, this is an optional directory so you can really keep them wherever you like. Source code is not relevant after you've compiled it into an executable so the system will never require the source of something to be accessible at a specific location.

In conclusion: /usr/src is a pretty standard location but feel free to choose your own if you prefer.

  • 6
    Just be aware that you really do not want to be messing with /usr/src on a non-Linux system. The BSDs keeps their base system sources there by default and you don't want to intermingle them with third-party software. Just build in your $HOME somewhere... – Kusalananda May 2 '17 at 18:00
  • 1
    The same applies to some sub-directories of /usr/src on Debian derivatives, if you have certain packages installed (gcc-6-source, binutils-source, DKMS packages, the kernel headers etc.). On Debian, there’s a nice feature where you can add yourself to the src group which owns /usr/src, and then just write there as yourself (without needing to sudo or whatever). – Stephen Kitt May 3 '17 at 8:09
  • And on Fedora, you shouldn’t touch /usr/src/debug and /usr/src/kernels (AFAICS). – Stephen Kitt May 3 '17 at 8:12
  • "Source code may be place placed". Is "place placed" a typo, or am I missing something? – Faheem Mitha May 3 '17 at 8:27
  • 3
    I'll go further and say you shouldn't really be touching /usr on any system. You should be putting things in /usr/local. Do BSDs mind you using /usr/local/src? – Muzer May 3 '17 at 11:21
11

/usr/local/src is a safe place to keep source code, and build it too. The FHS says:

Directory   Description  
src         Local source code

and also

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.

It's not clear what "Local source code" means, but it's clear the system isn't going to try to place anything in /usr/local/src, unlike /usr/src, so there seems to be little downside to putting code there.

In fact, I have mine on a separate filesystem:

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/data-local_src     79G   46G   30G  61% /usr/local/src

Note: at least on Debian, your user needs to be added to the staff group in order to write to /usr/local.

  • +1 for pointing out /usr/local/src while the other answers only discuss /usr/src – MattSturgeon Jul 6 '17 at 22:34
  • As for what "local source code" means, in general it means controlled by the local sysadmin rather than by a distribution. The same as everything else under /usr/local (in theory). So essentially it means exactly what you described. – MattSturgeon Jul 6 '17 at 22:38
9

If by "standard" you mean conventional, then the place to unpack and build source code is your home directory. Such files are expected to be transient, deleted when you are done, or kept if you like, organised however you please. Your home directory is your area to play with all this kind of stuff.

If you do wish to keep them afterwards, for reference, the "Filesystem Hierarchy Standard" recommends /usr/src. However, this is a guide not a law; and, if you were to get into this habit then venture onto a non-Linux system, you are liable to cause trouble by following it. For example, on a BSD system, base system sources are kept there and you really don't want to be messing with those. Even on Linux you may run the risk of mingling with any source stored by package managers, which is not desirable.

I would recommend avoiding /usr/src overall. There's no obvious benefit to keeping anything there at all, and potential risk if you confuse its intended meaning.

5

You can use /usr/src as this place sound reasonable and rpm based distributions use it to store there content of srpm packages. But any other place like /opt, /usr/local, ~/src is good

  • "rpm based distributions use it to store there content of srpm packages." That is exactly why you shouldn't store your own non-distro sources there and rather use /usr/local. - "That must be a good place to store stuff, with all these forklifts around that seem to be of the same opinion...." – rackandboneman May 3 '17 at 12:08

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.