On Sat, 14 May 2011 23:34:57 +0000 Christoph Anton Mitterer <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
