#75 Update to FHS section
Closed: Fixed None Opened 13 years ago by toshio.

Two changes for:

http://fedoraproject.org/wiki/PackagingGuidelines#Filesystem_Layout

== Use of /run instead of /var/run ==

Add a new section:

=== /run ===

System services may need to store run-time variable data somewhere
before /var/run is mounted. Currently, many programs are abusing
/dev for that purpose. A few distributions have figured out elaborate hacks to use /var/run even before /var itself is mounted to do this. This is seen as less than ideal, however. Several major distributions have committed to support using /run for this purpose instead.

For now, applications can use /run or /var/run almost interchangably. /run MUST be used when the application can be started during boot before /var may be mounted.

{{admon/note|/run ticket for FHS|http://bugs.freestandards.org/show_bug.cgi?id=718}}

== Specify that packages can't create directories outside of FHS ==

Add this admonishment to the introduction:

{{admon/note||Some interpretations of the FHS are that they do not prevent distributions from creating and using directories outside of the listed hierarchies (for instance, adding new toplevel directories or adding new directories under /usr). For the purposes of the Fedora Packaging Guidelines, new directories of this sort are not allowed unless listed in the Guidelines. If you feel the need for a new directory, please contact the FPC with a rationale for the directory and what category of software belongs in that directory. You may need to read the FHS to tell when a directory is part of an FHS approved hierarchy and when it needs an exception.}}


Until the FHS might be changed (or not), -1 from me to this proposal.

/run is prohibited by the FHS and therefore must not be used in Fedora.

FHS permits distributions to make such changes and even the FHS co-author agrees with this change (https://lwn.net/Articles/436177/). We have a number of other differences that FHS doesn't explicitly talk about either including libexec /selinux and so on. So stop quoting FHS as a reason and take into consideration why this change is being made and the benefit of it.

Unfortunately given the moribund state of the FHS, I do not see it as productive to block our process on their process (assuming there's even a "they" and they even have a process).

The change is needed, even if the way that it was gone about was not the best.

+1 from me. (Not that it really matters anyway, because it's already done, but I'd still have voted for it if they had asked first.)

+1 (same rationale as tibbs)

Dito.
+1.

I do have a question though ... AIUI systemd is "taking over" /var/run via. tmpfs, does anyone know what it is doing about /run ?

Replying to [comment:6 james]:

Dito.
+1.

I do have a question though ... AIUI systemd is "taking over" /var/run via. tmpfs, does anyone know what it is doing about /run ?

/run is a tmpfs; /var/run will either be bind-mounted or symlinked to /run.

The technical rationale for this change is sound and doesn't violate the letter or the spirit of the FHS. +1 from me as well.

+1, same as tibbs and rdieter. I'd love to see FHS revived.

Rahul -- as a member of the FPC voting on this proposed Guideline change, racor certainly has the option of voting against this based upon his interpretation of the FHS and his judgement of the relative merits of following it in this case vs the benefits of using the new directory. it's quite appropriate for him to mention in this ticket that lack of support in the FHS for the /run directory is his rationale for voting against the changes. Thank you, though for pointing to the post by Rusty Russell. That's another nice vote in favor of the /run directory.

I'm +1 to these changes as well. The FHS allows for Linux distributions to share a common file structure so that upstreams for software and system admins having to use different distributions of Linux can have valid expectations on both of them. For the section on /run, the consensus that's been built between distributions makes it a good supplement to the standard. For the section clarifying the prohibition on creating directories outside of the FHS in the general case, limiting the directories helps to keep the expectations about where certain types of resources will be located for the purposes of deciding what needs to be backed up, what sections of the filesystem can be shared among machines, etc.

Currently at (+1: 6, -1: 1, 0: 0) with no votes recorded for spot or laxathom. Five is needed to pass so this looks to be approved.

Guidelines updated.

https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

Announcement text:

"""
https://fedorahosted.org/fpc/ticket/75

The Packaging Guidelines have been updated to allow the use of /run and to clarify that directory hierarchies not listed in the FHS are not allowed unless listed in the Packaging Guidelines.
"""

Let me add this:

a) The FHS does not destinguish between "system" and "applications". I.e. the foundations the rationale the proponents of this proposal apply, does not hold.

b) The spirit of the FHS is to supply a common basis for all OSes and portable applications, to prevent OS vendors and application implementors from adding directories ad-lib by themselves.
This is exactly what Fedora/RH/systemd are doing by implementing /run.

The spirit of the FHS is to supply a common basis for all OSes and portable applications,

That's right. But you see, application portability is not harmed in any way by this change. Applications not involved in the early boot process are free to continue using /var/run which is as portable as it always was.

Standardizing /run enhances the portability of those "applications" (if you insist on calling them that) which are involved in booting and therefore cannot use /var/run. Before /run they had to use ugly non-portable hacks (/dev/.*, /lib/init/rw/). That surely was a gross abuse of FHS-specified directories.

This is exactly what Fedora/RH/systemd are doing by implementing /run.

You make it sound like "Fedora/RH" is the only one doing this. At the very least openSuse, Debian, Ubuntu participated in the /run proposal, welcomed it, and/or are already working on implementing it.

Also systemd is not the only software taking advantage of /run. There are at least these more: udev, dracut, lvm, mdadm, util-linux, bootchart.

The right way to create standards is being observed. Consensus were reached among developers and distributions. Then it was implemented. Codification of the standard in FHS can follow (if FHS is really not dead).

Metadata Update from @limb:
- Issue assigned to spot

7 years ago

Login to comment on this ticket.

Metadata