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