Le 11/09/2012 13:44, Colin Guthrie a écrit :
'Twas brillig, and Guillaume Rousse at 11/09/12 11:47 did gyre and gimble:
Le 11/09/2012 12:23, Sander Lepik a écrit :
11.09.2012 13:15, Guillaume Rousse kirjutas:
[...]

The /run - /var/run merge (/usrmove) is supposed to make the change
transparent for applications. Manually converting applications to
explicitely refers to the new location doesn't change its usefulness.

Well, if your system can't mount /var for some reason then keeping
things on /run might make recovery easier.

Then we probably should not refer to systemd directory as
/usr/lib/systemd, but as /lib/systemd for exactly the same reason.

I don't really see the comparison here.
The point was: if the canonical path for /usr/lib|/lib directory (which is actually the same) if the longuest one, why should the canonical path for the /var/run|/run directory be the shortest one ?

systemd is build to use /usr/lib/systemd these days, so it's technically
incorrect to refer to it as anything else (of course technically
incorrect != practically incorrect!)

Also, the usefulness of an available /run when /var is quite discutable,
whereas its main purpose is to store pid files for backgroud processes,
most of them using /var/lib for storing their data.

Well, not just pid files. It also stores socket files which are critical
for IPC and such like and is an important bridge between initrd and the
real rootfs.

Personally I'm more in favour of using /run directly and adding lint
rules that cause a build failure if files are packaged in either
/var/run or /run.
Shipping /var/run or /run files/directory is a different issues, and is rather related to tmpfs conversion.

However, a distinct lint rule could be to disallow the creation of /var/run subdirectories in tmpfiles.d configuration files, or to use /var/run pathes for PID files in systemd unit configuration files, if /run is to be preferred.

If nothing else it's marginally more efficient to use /run. No spinning
media stat required to dereference the index. In extreme cases, it will
help extend battery life. The benefits are tiny I'm sure, but it does
depend on context/setup and if there is no other tangible reasons, maybe
even this small advantage is enough to sway in one direction rather than
the other!
Well, I'm not really impressed by potential perf issues, especially with no backing benchmarks. I'm rather concerned about ease of maintainance, and consistency between spec files.

Anyway, I just found out than /usr/lib and /run are the actual directory, with /lib and /var/run the symlinks. Which makes an argument of favor of considering the first one as canonical.

--
BOFH excuse #182:

endothermal recalibration

Reply via email to