CODEWITHSUNDEEP
debian-packagingfhs
Matt Tsōnto
Matt Tsōnto

Reputation: 1702

Filesystem Hierarchy Standard: Where should my package install files in Linux?

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.

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

Upvotes: 1

Views: 469

Answers (1)

Andrew Henle
Andrew Henle

Reputation: 1

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.

Upvotes: 2

Related Questions