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

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0



On Mon, 18 Jan 1999, Andrew Josey wrote:

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

While I originally agreed with this decision, I'd like to see it revisited.
Doing this would restrict the set of applications the LSB applies to, while
I'd like to see it as general as possible. Ideally, the Cobalt web cube 
should be able to be an LSB compliant system without including X Windows,
for example.

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

I don't like the FHS being this heavy handed; I think /boot may exist, and
the kernel will be in / or /boot would be sufficient.

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

I would like to see a /lib/modules/preferred (this is implemented in RH 5.1+)
standardized. It's certainly reasonable for it to be an optional component.

> The fvwm package does configuration using cpp.
> 
> Netbase suggests cpp.
> 
> Regina-dev depends on cpp, as does:
>    wmaker and xlib6-dev

As does Enlightenment.

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

I can't stand /opt; that said, many ISVs prefer it.

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

These should be left out; I don't want the LSB to start mandating configuration
files and configuration file formats. 

> /usr/X386
> [The FHS2.0 mandates this - is it time to drop the requirement?]

Definitely, this is silly. Red Hat hasn't shipped this by default in
years.

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

How about /var/mail and /var/spool/mail must resolve to the same directory;
the actual location of the directory is implementation dependent.

> /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".

So we're requiring lpd as the spooling mechanism? While standardizing
lpr is sane, standardizing the mechanism isn't (imnsho).

> /usr/src/linux (should be required only in conjunction with a C
> compiler).

Shouldn't be required at all; /usr/include/linux and /usr/include/asm (etc) are
sufficient.

Comments are welcome.

Erik

-------------------------------------------------------------------------------
|       "For the next two hours, VH1 will be filled with foul-mouthed,        |
|          crossdressing Australians. Viewer discretion is advised."          |
|                                                                             |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad    |


Reply to: