Hi, Mats Wichmann wrote on Fri, Jul 01, 2011 at 08:15:29PM -0600: > On 07/01/2011 02:04 PM, Lennart Poettering wrote:
>> Note tht /var/run and /var are identical, since the former is just a >> symlink to the latter (or, on upgraded systems a bind mount). That means >> that if there's an utmp file in one of the two dirs there's one as well >> in the other -- and actually the very same file. > well, there must be a way to get there without that happening. Here's > from my system. They're not the same; they're neither symlink nor bind > mount; and the contents are not at all identical. [...] That's one of the main reasons why i think compatibility symlinks for system directories are not likely to happen on OpenBSD. They apparently cause confusion, and simplicity and clarity are among the goals we value most. Who is going to figure out what /run and /var/run are supposed to mean, and whether they are the same or not, if even OS developers wonder like this? Citing another post: From: Steve Langasek <[email protected]> Date: Sun, 26 Jun 2011 07:58:40 +0100 Message-ID: <[email protected]> > Treating any such directory as "optional" undermines the utility > of the FHS. > As I've pointed out in another thread, the only things that > are "optional" in the current FHS are subsystems that may be absent > from the system - there are no directories in the standard which allow > for implementors to put the indicated contents somewhere else (with > the exception that architecture-independent shared data is allowed > to be shipped in a per-application directory under /usr/lib instead > of /usr/share). You do have a point here. However, and i think deplorably, this is a point where different operating systems plainly have different necessities. From an OpenBSD point of view, /var/run perfectly fits the description of the purpose of /var in chapter 5: /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. Hence, i'm not aware of any plans to move this directory somewhere else or even symlink it from somewhere else. That would just muddle up the file system structure, in particular the root directory. Some Linux distributions have apparently made design decisions regarding some software that plainly don't work with the FHS as it's currently specified. Now there are three ways one could go: - Tell those distributions that they broke the standard and should fix there software. Not realistic, i fear. - Tell everybody else to move their stuff around because someone broke the standard. Not realistic, either. - Admit that different systems use different places for this purpose. Yes, that does reduce the utility of the standard. But i don't see how that can be avoided. So, i think /var/run should stay untouched in the standard, and the Linux section could say that on Linux, it is acceptable to symlink or bind mount or whatever that to /run. > Now, backwards-compatibility symlinks (or bind mounts) are perfectly > fine, such that the same contents are exposed under two directoriese. > If early-boot writable filesystems are irrelevant to the OpenBSD > implementation, the FHS allows for /run and /var/run to be symlinked > together. But the point is that they *would* need to be symlinked, > so that software relying on this provision of the FHS can access data > via /run as needed instead of having to work out whether the current > system is one that ensures /var is mounted early enough. I think relying on *any* directory to be present on a system in the build system of any portable application software would be bad design in the first place. When a portable application software build system requires hard-coded paths, you need some way to configure those paths for the system at hand, anyway, for example with config.h or something similar. Yours, Ingo _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
