Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
> 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.
I don't see any reason to mandate the directory, but have it only
optionaly empty.
I'd prefer things like "if you have kernel modules, they should/must
be in /lib/modules.
Then a system without any kernel modules and without /lib/modules (which is
not needed on that system) is ok...
> > /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.
All these things show the age of FHS 2.0.
> > Shouldn't this be /var/spool/mail with an optional symlink from /var/mail?
This is one of the things that seems much more critical than anything else to
me. I have changed my system 1995 to have all my binaries use this new
directory /var/mail and changed it back when I started to work for SuSE in that
year.
>From what I know about Debian, they wanted to change it to /var/mail, but
decided not to.
I don't see any reason to push in /var/mail. That will only result in
"mixed" systems, where some binaries default to one or the other
default directory. (I know that the environment-variable MAIL can
be set for most programs, but that doesn't fix everything...)
As a result, all Linux systems will have to provide both, where we
currently ship with /var/spool/mail only.
So if there are no other bigger standards that would make it very
convenient to move all Linux-distributions to /var/mail and
abandon /var/spool/mail, I'd hope that /var/spool/mail will be
listed as de-facto-standard of Linux systems.
> >
> > 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.
Why introduce another dir if all agree on one dir at the moment? Are
other unices the reason for this?
> > /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.
These dirs might vanish in the future. glibc will make more and more progs
totally independent of the kernel includes and Linus also wants to have that
direction.
My personal machines don't have any /usr/src at all, if I don't have
rpm installed. The kernel include files are part of /usr/include and no
symlinks to /usr/src/linux. No compiler should be confused by this.
Florian La Roche
Reply to: