On Wed, May 18, 2011 at 04:13:50PM +0100, Tony Travis wrote: > On 18/05/11 15:40, Jeff Licquia wrote: > > [...] > > OpenBSD was involved as well: > > > > http://marc.info/?l=openbsd-tech&m=130499860531930&w=4 > > > > The conclusion, all around, was that *BSD wasn't interested in the FHS.
That's a shame, but not entirely unexpected. Reading the various threads, many of the responses appeared to focus on the past rather than how this would be beneficial in the long run. But contacting them was definitely the right thing to do. > Actually, I think it should be the other way around: The FHS should be > interested in how *BSD filesystems are configured, because the FHS is > intended to be a platform independent standard for Posix-like systems. I'm in agreement with this. Having had a look at some of the hier(7) manpages, I can see some of the BSD point of view. The FreeBSD 8.2-RELEASE version, for example, is quite detailed. However, the detail includes a lot of information about where specific programs or subsystems store their files, rather than focussing solely upon the main hierarchy alone. I think that it's worth ensuring that the core directories in the FHS match those found on BSD, but to exclude program-specific ones. It makes sense for the FHS to be a superset of existing practice, but at the same time it doesn't make sense to standardise where individual programs store their files--it can change over time and become restrictive. Directories not in FHS: /libexec/ /usr/libexec/ /usr/libdata/ [unsure if this exists on all BSDs] libexec is already reported as missing in the FHS; having the FHS aligned with the current GNU coding standards is, IMHO, even more important than BSD compatibility (regarding installation directories only since the rest isn't relevant to the FHS). I'm not sure how libexec would work with the move to multiarch (same as lib?) For all the assertions that the BSDs are historically too different to adopt the FHS, pretty much all the rest isn't system-specific, it's program-specific (at least in Linux terms; BSD does of course include the basic subsystems and tools where on Linux they are mostly optional or interchangable). e.g. /dist/ (installer-specific) /etc/ppp (ppp-specific) /rescue/ (rescue-tools specific) /usr/include/arpa (specific subdirs don't need standardising) /usr/obj/ (ports-specific) /usr/ports (ports-specific) /usr/share/doc/ncurses (app-specific) /usr/share/groff_font (app-specific) /usr/src/* (BSD sources) /var/db (system databases maintained by system) Summarised, I'm just trying to say that the FHS and hier(7) have different purposes. If you exclude the application-specific aspects of hier(7), what's left is mostly, if not entirely, compatible with the FHS. From this POV it shouldn't be difficult to add the few missing dirs to the FHS and leave all the specific bits up to the implementor. i.e. a BSD system would then automatically be FHS compliant; it's free to add extra stuff such as /usr/ports already. It's certainly worth keeping the Linux-specific aspects of the FHS separate as they are now, and if any are found in the main text, moving them there. Also, where parts of the standard are duplicated in POSIX, you could remove them and delegate that part to the POSIX/SUS standards, e.g. required programs in /bin and /sbin. /boot is somewhat LILO-specific (referring to the "map installer"). Likewise /etc does make some program-specific assumptions e.g. that the system init uses /etc/inttab and that lpd uses /etc/printcap. Looking at it, only a few files listed here are actually needed for the system to function (passwd, group, resolv.conf, shells etc.); program-specific stuff like mtools.conf, hosts.lpd, ftpusers, X11 etc. is a bit pointless, and in many of these examples, long outdated-- it it worth going through the FHS text and removing program-specific stuff so that it just focusses on their hierarchy itself? (Or, where required, moving them into a specific annex?) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
