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 .
regards
Andrew
-----------------------------------------------------------------------
Resolutions to comments received on
the December 11th draft of the
LSB-FHS-TS_SPEC_V1.0
(ftp://ftp.xopen.org/pub/lsb/test)
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
circumstances.
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)
Problem:
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).
Action:
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
processor.
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)
Problem:
/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
LSB-FHS-TS_SPEC_V1.0
Action:
Make clear that subdirectories may exist under /mnt to which temporary
filesystems are mounted.
Reviewer Reponse:
[Accept]
@ 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:
/etc/exports
/etc/ftpusers
/etc/hosts.allow
/etc/hosts.deny
/etc/hosts.equiv
/etc/hosts.lpd
/etc/printcap
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)
Problem:
I believe this is specific to the Intel platform.
Action:
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
compiler).
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)
Problem:
The bootloader program lilo is specific to the Intel platform,
on sparc it is called silo (I believe Alpha uses milo).
Action:
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: