[Annatar]

The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, "for third party and unbundled applications". Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can never be delivered into /usr, because that is vendor's namespace, and an updated version from the vendor might very well bring a production application down).

/opt: application payload

/etc/opt: application's configuration files

/var/opt: application's data.

For applications with more than two configuration or data files, it is a good idea to create /etc/opt/application and /var/opt/application.

If your company is mature enough to understand what system engineering is, and employs dedicated OS and database system engineering departments, /opt/company, /etc/opt/company[/application], and /var/opt/company[/application] become very practical. If this approach is combined with delivering the application payload and configuration management as operating system packages, one only need worry about backing up the data in /var/opt, and that's it.

[majewsky]

> Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems

What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.

[Annatar]

> Why should it be impossible for a third-party package to just create /opt?

It is not impossible, obviously, but /opt and such should come from the operating system's vendor, and the vendor should be the only one to decide which filesystem permissions to provide: 0755? root:bin or root:sys? root:root? bin:bin? The vendor should decide that, since a vendor is supposed to know their operating system best.

Third parties might not agree, or even decide correctly for that operating system.

This is system engineering and architecture, something which beside operating system vendors, software vendors do not have a clue about in the slightest.

[dingaling]

Indeed Adobe Reader for Linux used to land itself in /opt on Ubuntu.

The power of run-as-su installers...

[Annatar]

The FHS thing in Debian and Ubuntu must be relatively new, I certainly have no recollection of it back then when we looked into delivering unbundled software for it. And we did look for it, and we even combed through the Debian packaging specification back then.

Whatever it might be, or has been, if Debian and Ubuntu did get /opt, /etc/opt, and /var/opt and are now one small step closer to being System V compliant (from which FHS stems), I for one am very glad for that.

[jwilk]

Debian does include /opt and friends, as required by FHS: https://sources.debian.net/src/base-files/9.6/debian/postins...