1

I'm looking for help understanding the FHS, particularly as it applies to software I'm developing. There seem to be nuances that neither I nor my colleagues are aware of.

I'm especially confused about whether the executable binaries are considered "shareable" files and/or "locally installed software" and/or "add-on application software packages". I wouldn't expect those to be mutually exclusive, but the FHS gives different locations for each.

For background: The software is a partially-privileged system service, part of a suite of security software. It's not considered critical to the boot process. I'll be distributing the software as deb and rpm packages. It's commercial, closed-source software.

  • /usr: "shareable, read-only data" [FHS 4.1], where "shareable" is "can be stored on one host and used on others" [FHS 2] Seems to fit, since AFAIK the binaries could be installed on one volume that's mounted to several hosts.
  • /usr/local: "Locally installed software must be placed within /usr/local rather than /usr" Also seems to fit, since the binaries could be installed locally.
  • /opt: "for the installation of add-on application software packages" [FHS 3.13] Since the software isn't part of a distro, presumably it would count as "add-on", and it's being distributed as a "package".

So which is right, and why? I'm hoping that when I understand that I'll be able to figure out the rest.

Matt Tsōnto
  • 1,518
  • 1
  • 15
  • 30
  • adding debian-packaging because those folk are likely to know the answer, and I'll be making Debian packages (among others) – Matt Tsōnto Oct 19 '22 at 21:00

1 Answers1

2

In my opinion:

  • /usr - Leave it alone, IMO it's for the OS installation and the OS installation only. Per FHS 3.0: "Large software packages must not use a direct subdirectory under the /usr hierarchy." So you're sharing /usr/bin with the OS.
  • /usr/local - Tends to be used by local admins, often to build software, so isn't really the safest place. I like to think of /usr/local as the "local" playground for the system's admins - IMO it's theirs to put their "locally installed (and likely locally built) software" in.
  • /opt - Designed for non-OS packages. Avoiding collisions in /opt is easy if you have a distinctive name. Per FHS 3.0: "/opt is reserved for the installation of add-on application software packages." That seems to be exactly what you're delivering. I suspect it wouldn't be hard to get a unique LANANA-registered name, giving you at least some degree of certainty that you won't have a collision. I suspect the reason many organizations don't use /opt is that making your software self-contained - like being able to locate its shared objects - is a bit harder.

Given all that, IMO the best place is /opt. You're less likely to have a name collision, and less likely for a local admin cleaning a botched build out of /usr/local accidentally nuking your installed software.

Andrew Henle
  • 32,625
  • 3
  • 24
  • 56