See the following entries in 16.5 Variables for Installation Directories from the GNU coding standards:

[[

‘localstatedir’

The directory for installing data files which the programs modify while they run, and that pertain to one specific machine. Users should never need to modify files in this directory to configure the package’s operation; put such configuration information in separate files that go in $(datadir) or $(sysconfdir). $(localstatedir) should normally be */usr/local/var*, but write it as *$(prefix)/var*. (If you are using Autoconf, write it as ‘@localstatedir@’.)

‘runstatedir’

The directory for installing data files which the programs modify while they run, that pertain to one specific machine, and which need not persist longer than the execution of the program—which is generally long-lived, for example, until the next reboot. PID files for system daemons are a typical use. In addition, this directory should not be cleaned except perhaps at reboot, while the general /tmp (TMPDIR) may be cleaned arbitrarily. This should normally be */var/run*, but write it as *$(localstatedir)/run*. Having it as a separate variable allows the use of /run if desired, for example. (If you are using Autoconf 2.70 or later, write it as ‘@runstatedir@’.)

]]

How can $localstatedir be $prefix/var and at the same time $runstatedir be /var/run (notice no prefix) if it is defined as $localstatedir/run.

Since the FHS doesn't define /usr/local/var, and my Debian system lacks it, and I don't think people are going to start symlinking /usr/local/var to /var, I guess the coding standard really intended to define $localstatedir as /var.

The bug is also present in the GNU Make documentation, which seems to be just a copy of the GNU coding standards.

Cheers,

Alex

Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://www.gnu.org/software/make/manual/html_node/Directory-Variables.html>

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to