[fhs-discuss] Merge FHS with BSD filesystem standard?

[Ingo Schwarze]

Hi Jeff,

Jeff Licquia wrote on Wed, May 18, 2011 at 10:40:11AM -0400:
> On 05/17/2011 12:04 PM, Julian Fagir wrote:

>> this request was already made:
>> http://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011439.html
>> The NetBSD-mailing list had a longer discussion about that:
>> http://mail-index.netbsd.org/tech-userlevel/2011/05/10/msg005050.html

> OpenBSD was involved as well:
> http://marc.info/?l=openbsd-tech&m=130499860531930&w=4

Right, and i sent a list of suggestions

  http://marc.info/?l=openbsd-tech&m=130503366832069&w=4

and am reading fhs-discuss@ since that time.

> The conclusion, all around, was that *BSD wasn't interested in the FHS.

That is not completely off the mark, but still a slight overstatement.

Sure, FreeBSD, NetBSD and OpenBSD are not likely to implement
major changes to hier(7) to better conform with the FHS;
hier(7), and not the FHS, will continue to be the main tool
for keeping *BSD file system layouts consistent; and many *BSD
developers apparently expect very little help from anything
related to the FHS.

However, a few have expressed hope that improving the FHS might
help to reduce porting issues, and a few have provided specific
feedback and suggestions.

After looking through most of the discussions, i think the basic
decision you, as the FHS maintainers, need to make, is this:

 1) Either work towards a version of the FHS where the
    general part agrees with all major UNIX-like operating
    systems, in particular Linux, the major BSDs, and Solaris,
    slowly moving the Linux-specific content to the Linux chapter,
    and point to the hier(7) documents for the equivalent
    of the Linux chapter on the BSDs.

 2) Or rename the FHS to "Linux file system hierarchy standard",
    merge the general and Linux sections, and point people searching
    for more general information on UNIX-like operating systems
    to the hier(7) documents of the various operating systems.

The advantage of option (1) would be that it helps software
authors caring about portability, because they need not compare
various documents scattered around the web, but could find the
largest common denominator in one place.  Another advantage might
be that Linux might be less likely to further drift away from
other systems without having good reasons, merely because the
differences would remain visible to the Linux world.

Maybe it would even be advantageous in the long run to add
very brief chapters regarding other systems to the FHS, addressing
just the most important points unlikely to change, not going into
all the details, not so much because such chapters would directly
steer development, but because such brief summaries could help
mutual understanding and help software authors to get a general
feeling which most typical portability issues to expect.
Just as an example, a chapter on OpenBSD might say that
 - /bin and /sbin are not allowed to contain any dynamically
   linked binaries, but only static binaries and sh(1) scripts
 - files installed by packages must not be outside /usr/local,
   and nothing else must be inside /usr/local
 - /usr/local/etc must not exist
 - /usr/libexec must exist, but never be in the PATH
 - /usr/src, /usr/obj, and /usr/ports are used, and what for
 - but not much beyond that, instead pointing to hier(7).

The prices to pay for (1) would be 
 - a slightly larger maintenance effort for the FHS working group,
   because changes related to non-Linux operating systems would
   need to be incorporated.  However, given the differences between
   different systems, the general part of the FHS is not likely to
   be that large, and some of the work might get done by submissions
   from *BSD contributors who would not contribute to an FHS taking
   the second route.
 - that the FHS would be slightly harder to read from a purely
   Linux perspective.  However, whether that is an advantage
   or an inconvenience is a matter of perspective:  Do Linux
   people want to know what other UNIX-like systems do?
   If yes, the slight complication is an asset, otherwise,
   a downside.

Yours,
  Ingo

-- 
Ingo Schwarze <schwarze at openbsd.org>
maintainer of the OpenBSD documentation formatting tools