Ian Jackson <[EMAIL PROTECTED]> writes: > What used to be the FSSTND group has changed composition somewhat, > and now includes a number of people from the BSD world. It set > itself the goal of producing a joint filesystem layout standard, > named the FHS.
Actually, the vast majority of people on the mailing list are Linux people (about 95%). The BSD people are lurking, partially because you scared them off, and I have my doubts that a joint standard will ever exist. The BSD people have been helpful with /usr/share and /usr/libexec, and I think it would be a shame to completely sever relations, even if a 100% joint standard doesn't happen. > The latest draft FHS, which they may well publish as it stands, makes > the following changes with which I have very strong disagreements: > * The mail spool, /var/spool/mail, is moved to /var/mail. This change is probably the most noticible, but places the FHS with the majority of the modern Unix community. Solaris, BSD, IRIX, etc. Transition from /var/spool/mail to /var/mail is not difficult. Change a line in paths.h, add a symbolic link, and change any mail programs that don't use paths.h (as they should). > * /var/lib is renamed to /var/state (yes, all of it). Again, transition is easy. Single applications can be modified, one at a time. A symbolic link can be used or you can go with two separate directories (/var/lib and /var/state). > * /var/lib/games is moved to /var/games. I recently proposed removing /var/games (/var/lib/games, whatever) from the draft before release. But, since you're working over (flaming over) your backlog of mail without reading it all first, you haven't seen my proposal yet. Games, with the exception of the binary location (/usr/games) don't need to be treated differently from other applications. So I want to remove this unnecessary complication. > * A new directory /usr/libexec is created to hold command binaries > used only internally by programs - these are to be moved from > /usr/lib and in some cases /usr/sbin. Oddly there is no > corresponding /libexec directory. I am not opposed to a /libexec directory. It has been mentioned, but nobody has proposed it. The need is minimal. Note that there is also no /share. If /libexec was added, it might also make sense to add /share. > [...] Ian, here is the extent of your participation in the last year. 1. Get upset over some changes. 2. Flame all over because of those changes, a long period of time after the fact. 3. Offer no proposals, but be free with ultimatums. I'm sorry to be so blunt, but the trend is clear. I realize that there are many changes in the current draft, but it's been 18 months since the last FSSTND was released. It will probably be another year after this release before the next. In addition, to ease transition from FSSTND 1.2 to FHS, I am implementing a FHS WWW site including a developers section with migration information, how to deal with the GNU coding standards and autoconf (it will be easier after FHS than with FSSTND, by the way), etc. Before members of the Debian community decide whether or not to support the FHS in your internal discussion, I encourage you to read the current draft of the FHS rather than Ian Jackson's summary. I would be very hesitant to release FHS if it meant losing a previous supporter, whether it be Debian or another distribution. Ian, please consider writing a proposal to revert some of the long-past changes (perhaps one message per major proposal) that you don't like. It is always easier to be a positive proactive force than a negative reactive one. Regards, Dan -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
