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 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) -------------------------------------------------------- @ 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: [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) 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.] @ 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 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] @ 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) 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: [] @ 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 compiler). Reviewer Response: [] @ 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.] Draft 18 January 1999 ----- Andrew Josey The Open Group Senior Test Development Manager Apex Plaza,Forbury Road, Email: [EMAIL PROTECTED] Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
