[fhs-discuss] minor issues

[Karl Goetz]

On Sat, 14 May 2011 23:34:57 +0000
Christoph Anton Mitterer <calestyo at scientia.net> wrote:

> Hi.
> 
> Here some minor issues I'd change:
> 
> 1) Require the "printf" program to be present in "/bin".
> POSIX/SUSv3 suggests to use printf instead of echo, this is however
> not easily possible, as "printf" is not guaranteed to be there in all
> circumstances (e.g. during boot) because it's typically put in
> "/usr/bin" .

The current wording says bash must exist, so i guess this wasn't such
an issue (bash has printf as a builtin).
There is a bug about changing to reference posix instead of specifying
bash, perhaps this could be added as a prerequisite for that change.


> 4) It should be defined more clearly and strict, which hierarchies are
> required to be available when.
> e.g.
> - Which are expected to be there during all times (even booting)? e.g.
> /lib/, /bin, /sbin are ... /usr, /home is not.... but what
> about /root/, /var/run and friends?
> - Which are not?
> - Should thinks like Linux' initramfs be considered there?

minor comments here:
as /root is defined as optional, i'd say its implicitly not required.
/var/run is going to become /run (don't know if that affects your
comment or not)

> 5) Emphasis that "/mnt" is for a _single_ _temporary_
> mountpoint...i.e.:
> - nothing that should go to /etc/fstab
> - not having subdirectories (does cgconfig/cgred in Linux still use
> this?)

FHS already disallows using the directory by applications:

> This directory is provided so that the system administrator may
> temporarily mount a filesystem as needed. The content of this
> directory is a local issue and should not affect the manner in which
> any program is run.

If i was proposing changes I would rather suggest change the wording to
specify filesystem*s* (rather then the current filesystem) to allow the
practise of (for example) using /mnt/sdc4 /mnt/sdb3 to rsync data
between during recoveries.

> 6) Relax unnecessarily strict requirements:
> "/sbin" requires to have all fsck.* and mkfs.* tools.
> - IMHO it neither makes sense to restrict them to /sbin (but also
> allow /bin, because nowadays there may be filesystems that are
> user-centric (and not device-centric),... e.g. on could think of
> things like mkfs.gmail, which automatically registers a google
> account and mounts it in Linux via FUSE.

If you are proposing user mountable filesystems end up in /bin/, i'd
agree with that.

> - It also does not make to keep it away from the "/usr/bin" or
> "/usr/sbin"... as many of those filesystems are in no way required to
> boot or to run the system.

We can't know which filesystems this is in advance.

> 7) Getting rid of legacy stuff (e.g. X11R6 directories).

there are bugs about X11R6 and the */games directories, are there other
locations to look for?
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110517/ac015aad/attachment.pgp