[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Updated Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

hi All
I've done some updates based on email from yesterday. These are
marked with a double asterix (**).  Where some
of the issues seem controversial I've left them for the moment
to see what the concensus of the LSB-spec folks .

Resolutions to comments received on
the December 11th draft of the

Last updated 19th January 1999 - incorporated Alan Cox's
comments from 18 Jan email. Also reviewed mail from
Erik Troan and Florian La Roche - need to see the concensus
of the LSB spec folks before committing changes.


@ 0

Various games directories -- may not be appropriate in certain

Reviewer Response:
[Reject- The games directories are specified by the FHS2.0 spec.]

@ 0 , LSB extensions of FHS

The LSB mandates the inclusion of X11R6.

I think it might be better to name all of the as X11 and have a symlink from
X11R6 to X11 in all cases (/usr/X11R6 link to /usr/X11, etc..)

Reviewer Response:
[Reject - Not quite sure what the commenter is referring to]

@ 0 , /proc

What about /proc?

Reviewer Response:
[Reject - /proc is defined and there are tests based on the Linux Allocated
Devices Document]

@ 0  X11

Everything related to X11: X11 should be an optional component.  A
system designed for small footprint (e. g. firewall) may find it
undesirable to have X present on the system.  A system designed for
cluster use may not need X present at all.

Reviewer Response:
[Reject - The LSB team have decided that X11 is mandatory]

@ 3.1-29, /bin/setserial

/bin/setserial: I believe this should be a configuration option.
setserial is normally used during the boot process to set the speed on
a serial port, if it exists.  On a system with no standard serial
ports, this is not useful.  Example: Extreme Linux, which is designed
for clustering.

Reviewer Response:

[ ** Accept - this appears to be a problem with the FHS2.0 spec, as
/sbin/setserial does not appear on many non x86 platforms.
We need to feed this back to the FHS development group.
Should this be required only on x86? - updated based on Alan
Cox mail of Jan 18.]

@ 3.1-37 /bin/csh

/bin/csh: I think an argument can be made that this should be
mandatory.  csh and variants are very widely used.

Reviewer Response:
[Reject - in this respect the LSB is a minimalist specification.
I think that requiring the presence of /bin/sh is sufficient. Users can
lobby for the installation of their favorite shell package on a site by site
basis.  ]

@ 3.2 /boot

/boot: this is a low level system function; it should be
implementation-dependent where the kernel resides.

Reviewer Response:
[Whilst the FHS2.0 specifications states that /boot has to exist,
the kernel is allowed to be in either / or /boot]

@ Section 3.4 /etc, Reference 3.4-12(A)


The bootloader configuration file lilo.conf is specific to
the Intel platform, on sparc it is called silo.conf (I believe
Alpha uses milo.conf).


Either remove the test, or make it either manually configurable
or automatic using arch (or `uname -m`)

Reviewer Reponse:
[** This would seem to be a problem in the FHS2.0. We should suggest
a change there and then incorporate this on an architecture basis
as suggested. It also seems that LILO and lilo.conf are optional
even on x86 , and its looks like at best this should be an if
present , lilo.conf should be in /etc/lilo.conf - updated based
on Alan Cox email of 18 Jan]

@ 3.4.2-1(A), /etc/opt

Should you also require /usr/opt?

Reviewer Response:
[Reject - the FHS2.0 specification does not define /usr/opt, but instead /opt]

@ 3.6.2 /lib/modules

/lib/modules: this is not useful on a system without a compiler
(which is later listed as an option) that uses a monolithic,
non-modularized kernel, unless the specific intent is to allow
installation of third-party software with precompiled kernel modules.
The current Linux module architecture makes this a dicey proposition,
since a mismatch between kernel version and module version typically
results in a non-loadable module.

Reviewer Response:
[** Reject - Your set of criterion for rejection are insufficient.

On many systems, (most notibly toshiba laptops, among others) the hardware
can not boot a bzimage file. Installation programs are always too large
for zImage when a reasonable number of drivers are "built-in".

While delivering pre-compiled kernel modules is admittedly touchy,
delivering the source for inclusion in an existing kernel is not as much
of a problem. If pre-compiled modules are necessary, then it becomes
advisable to deliver a compatible kernel as well.

The location for these modules should be specified.

Note also that /lib/modules has only to exist, it could be empty!]

@3.6.6 /lib/cpp

/lib/cpp: this should be tied, at most, to the compiler requirement
(or is cpp envisioned for other purposes)?  C compilers are not
required by the C language specification to provide a standalone macro

Reviewer Response:
[Reject - Debian packages the cpp program separate from gcc, "to provide the
preprocessor for packages that don't need the compiler".

The fvwm package does configuration using cpp.

Netbase suggests cpp.

Regina-dev depends on cpp, as does:
   wmaker and xlib6-dev

While this is not a large list, the dependencies do exist.]

@ 3.7 , /mnt

I think instead of mounting things directly to /mnt, you could mount things
to a subdirectory of /mnt, like /mnt/floppy, /mnt/cdrom, /mnt/tmp,
/mnt/foo, etc...

Reviewer Response:
[Agreed, the FHS2.0 spec is not explicit on the directory contents]

@ /mnt , 3.7-2(B)

/mnt is typically used to contain multiple subdirectories where temporary
filesystems may be mounted.  (/mnt/cdrom and /mnt/floppy, for example)
This is more an error in the Filesystem Hierarchy Standard 2.0 then in

Make clear that subdirectories may exist under /mnt to which temporary
filesystems are mounted.

Reviewer Reponse:

@ 3.8 /opt

Get rid of /opt. It's an abomination to the free *nix world.

Reviewer Response:
[reject - /opt is defined in section 3.8 of the FHS 2.0 specification]

@ 4 /etc

Various services in /etc: many of these should be optional, but if
provided by the system, must be present in /etc.  In particular:


Reviewers Response:
[** The FHS2.0 specification as written seems to make these mandatory - we
need to get further feedback on this - since it would appear that
some of them are optional, for example /etc/exports need only
exist if exporting filesystems over nfs

There does seem concensus here, we need to identify which files
are mandatory if any]

@ 4.2 /usr/X386

/usr/X386 (as distinct from X in general, above): it is my
understanding that this directory has been obsolete for many years (I
believe it was obsolete well before libc5, in which case I think that
this should not be required unless the system supports running a.out
executables, which is not stated).  In this case, I do not believe
that any value is gained from requiring its presence.

Reviewer Response:
[** The FHS2.0 mandates this - is it time to drop the requirement?
Its also platform specific - see next item]

@ Section 4.2 /usr/X386, Reference 4.2-1(A)


I believe this is specific to the Intel platform.


Only perform the test on Intel (or compatible platform) by testing
arch or `uname -m`.

Reviewer Reponse:
[This would seem to be a problem in the FHS2.0. We should suggest
a change there and then incorporate this on an architecture basis
as suggested.]

@ 4.2-1(A) , /usr/X386

What is this for?

Reviewer Response:
[Reject - The FHS2.0 specification explicitly states that this directory
exists and is for X11R5 (it may be identical to /usr/X11R6.]

@ 4.5.2 sendmail

/usr/lib/sendmail: choice of MTA should be properly
system-dependent, and this will be of no use on systems using qmail or
the like to process mail.  Better would be to require /bin/mail to
inject mail into the system, I think.

Reviewer Response:
[** Reject - Nothing in the FHS says "/usr/lib/sendmail" is required to be
Sendmail 8.x.  Any mailer can provide a compatible binary interface for this.
Exim for example and Smail do.  ]

@ 5.7-1(A), /var/mail

Shouldn't this be /var/spool/mail with an optional symlink from /var/mail?

Reviewer Response:
[Reject - The FHS 2.0 explicitly states that the mail directory be /var/mail.]

@ 5.10-1 /var/spool/lpd

/var/spool/lpd: may not be necessary on a system not supporting
printing.  I think this should fall under the category "if printing is
present, this must be here".

Reviewer Response:

@ 5.13 /var/yp

NIS: should be optional (along with /var/yp).  If NIS is to be
present at all, there are issues to consider:

a) What level of support (NIS vs. NIS+).

b) What commands shall be supported (ypbind, ypwhich, ypcat, ypmatch).

Reviewer Response:
[ Accept -
Alan Cox writes: Definitely a good point. NIS is also a dying monstrosity.
glibc makes this even more complex with glibc 2.0.10x since it supports
stuff like hesiod and there are add ons for LDAP.  ]

@ 5.13 /var/yp

Note: Should presence of NIS be optional?

I think so...

Reviewer Response:
[ ** Accept - see previous comment]

@ 6.1.4 /sbin/lilo

/sbin/lilo (and other lilo machinery) should perhaps be left up to
the system.

Reviewer Response:
[** Accept with changes - see response to /etc/lilo.conf argument.
lilo may not be present on all architectures. This would
appear to be a flaw in the FHS specification.  ]

@ 6.1.6-1

/usr/src/linux (should be required only in conjunction with a C

Reviewer Response:
[** Reject: Perl and other programs have tools that parse system includes. It
isnt likely you would use them without a C compiler but it is possible.
Consider things like commercial C++ compilers, modula-2 etc]

@ Section 6.1.4 /sbin, Reference 6.1.4-1(A)


The bootloader program lilo is specific to the Intel platform,
on sparc it is called silo (I believe Alpha uses milo).


Either remove the test, or make it either manually configurable
or automatic using arch (or `uname -m`)

Reviewer Reponse:
[This would seem to be a problem in the FHS2.0. We should suggest
a change there and then incorporate this on an architecture basis
as suggested.]

Reply to: