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

Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

hi All,
Attached is a file of proposed resolutions. I'd appreciate feedback
on this - a couple of items have no response - for those I would
appreciate any proposals.
best regards


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


@ 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:
[Reject - The FHS 2.0 spec requires /sbin/setserial to be available on
all conforming systems]

@ 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.]

@ 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.]

@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]

@ 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?]

@ 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:

@ 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:

@ 5.13 /var/yp

Note: Should presence of NIS be optional?

I think so...

Reviewer Response:

@ 6.1.4 /sbin/lilo

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

Reviewer Response:
[reject - the FHS2.0 spec mandates its presense]

@ 6.1.6-1

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

Reviewer Response:

@ 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.]

Draft 18 January 1999

Andrew Josey                                The Open Group
Senior Test Development Manager             Apex Plaza,Forbury Road,
Email: a.josey@opengroup.org                Reading,Berks.RG1 1AX,England
Tel:   +44 118 9508311 ext 2250             Fax: +44 118 9500110

Reply to: