I’ve seen a lot of self-hosted software wanting to store their data in /opt, is there any reason why?
"Traditionally, the /opt directory is used for installing/storing the files of third-party applications that are not available from the distribution’s repository.
The normal practice is to keep the software code in opt and then link the binary file in the /bin directory so that all the users can run it."
Compare to a text version: http://www.slackware.com/config/rootdir.php
I was wondering about that too… According to the spec:
/home is a fairly standard concept, but it is clearly a site-specific filesystem. The setup will differ from host to host. Therefore, no program should assume any specific location for a home directory, rather it should query for it.
Sometimes home directories are in other locations. My University used to have different mount points for different graduating classes on our Unix servers. And I use “/home2” for one of my servers for… reasons.
Though I’m not sure that qualifies as “deprecated”? I get the “non-standard” bit though.
That’s what I was wondering as well?
If so, what’s the “correct” location to store stuff like documents, downloads, configurations, etc.?
My best guess is that having programs treat a user’s home directly as a location for things like config files is deprecated. Programs should be following the XDG standard instead.
You could contact the author (their email address is in the image), but I’m too lazy to do that.
Let’s say you want to compile and install a program for yourself from its source code form. There’s generally a lot of choice here:
You could (theoretically) use / as its installation prefix, meaning its binaries would then probably go underneath /bin, its libraries underneath /lib, its asset files underneath /share, and so on. But that would be terrible because it would go against all conventions. Conventions (FHS etc.) state that the more “important” a program is, the closer it should be to the root of the filesystem (“/”). Meaning, /bin would be reserved for core system utilities, not any graphical end user applications.
You could also use /usr as installation prefix, in which case it would go into /usr/bin, /usr/lib, /usr/share, etc… but that’s also a terrible idea, because your package manager respectively the package maintainers of the packages you install from your distribution use that as their installation prefix. Everything underneath /usr (except /usr/local) is under the “administration” of your distro’s packages and package manager and so you should never put other stuff there.
/usr/local is the exception. It’s where it’s safe to put any other stuff. Then there’s also /opt. Both are similar. Underneath /usr/local, a program would be traditionally split up based on file type - binaries would go into /usr/local/bin, etc. - everything’s split up. But as long as you made a package out of the installation, your package manager knows what files belong to this program, so not a big deal. It would be a big deal if you installed it without a package manager though - then you’d probably be unable to find any of the installed files when you want to remove them. /opt is different in that regard - here, everything is underneath /opt/<programname>/, so all files belonging to a program can easily be found. As a downside, you’d always have to add /opt/<programname>/ to your $PATH if you want to run the program’s executable directly from the commandline. So /opt behaves similar to C:\Program Files\ on Windows. The other locations are meant to be more Unix-style and split up each program’s files. But everything in the filesystem is a convention, not a hard and fast rule, you could always change everything. But it’s not recommended.
Another option altogether is to just install it on a per-user basis into your $HOME somewhere, probably underneath ~/.local/ as an installation prefix. Then you’d have binaries in ~/.local/bin/ (which is also where I place any self-writtten scripts and small single scripts/executables), etc. Using a hidden directory like .local also means you won’t clutter your home directory visually so much. Also, ~/.local/share, ~/.local/state and so on are already defined by the XDG FreeDesktop standards anyway, so using ~/.local is a great idea for installing stuff for your user only.
Hope that helps clear up some confusion. But it’s still confusing overall because the FHS is a historically grown standard and the Unix filesystem tree isn’t really 100% rational or well-thought out. It’s a historically grown thing. Modern Linux applications and packaging strategies do mitigate some of its problems and try to make things more consistent (e.g. by symlinking /bin to /usr/bin and so on), but there are still several issues left over. And then you have 3rd party applications installed via standalone scripts doing what they want anyway. It’s a bit messy but if you follow some basic conventions and sane advice then it’s only slightly messy. Always try to find and prefer packages built for your distribution for installing new software, or distro-independent packages like Flatpaks. Only as a last resort you should run “installer scripts” which do random things without your package manager knowing about anything they install. Such installer scripts are the usual reason why things become messy or even break. And if you build software yourself, always try to create a package out of it for your distribution, and then install that package using your package manager, so that your package manager knows about it and you can easily remove or update it later.
Add-on application software packages
How are applications that go into /opt different than any other packages? Even after reading that spec, it seems arbitrary.
Yes, it’s arbitrary.
Packages that bundle a bunch of stuff, or otherwise make a mess, should go into /opt. Well-behaved packages that integrate with the system should be fine to install to /usr.
Who gets the final call on that, the developer or the maintainer? I’ve noticed that Landscape goes into /opt, and Canonical is both developer and maintainer there.
