Re: Debian, Linux, the FSSTND, the FHS and BSD
From: Ian Jackson [EMAIL PROTECTED] I lost this argument, chiefly through a combination of poor politics on my part Ian, Don't feel bad that you're not good at politics yet - with my 39th birthday approaching I'm only just beginning to understand it. If you feel you've lost arguments through poor politics rather than through any fault in your logic, it's probably appropriate for us to put someone on the FHS who can maintain the necessary _distance_ required for this sort of argument. We value your services tremendously, and would be happy to see you spend more time on your thesis, dpkg/dselect, etc. ...with which I have very strong disagreements: * The mail spool, /var/spool/mail, is moved to /var/mail. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * 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'd be inclined to live with it. We can do the usual symbolic link hacks for Debian 1.2 to help ease the transition, and remove them for 1.3 . You can sum up anything else you disagree with for us on debian-devel. I will hear argument and set Debian's position on the standard. At the very worst, we would make a partial acceptance and produce a compliance statement that details any areas in which we depart from the standard. Thanks for working on this. I'm sorry, I didn't know you had such a depth of emotional involvement in it. Bruce Perens Debian Project Leader
Re: Debian, Linux, the FSSTND, the FHS and BSD
Ian Jackson writes: 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. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. I don't like either of these and IMO we shouldn't change. At least not in the near future. * 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. Sounds like a good idea for me. Since you once lobbied for this dir, why don't you like it now? The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. Sounds okay, too. Couldn't we make only the changes we like? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Re: Debian, Linux, the FSSTND, the FHS and BSD
You (Michael Meskes) wrote: Ian Jackson writes: 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. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. I don't like either of these and IMO we shouldn't change. At least not in the near future. We could ofcourse put in some symlinks (/var/state - /var/lib, etc). Just three of 'em and we'd be compliant :). One problem I see, one way or the other, is how is dpkg going to deal with this? I understand it has some trouble with files in symlinked directories or is that solved now? BTW. I'd prefer going along with the FSSTND at the moment that other distributions do it too. Can't we just wait and see what RedHat and others do? Even better, can't we discuss this with them (hmm Eric Troan isn't on this list is he :)). Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Re: Debian, Linux, the FSSTND, the FHS and BSD
Ian Jackson wrote: 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 is a positive thing. Both SVR4 and BSD 4.4 put it here. I think any contemporary unix should. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * 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 don't really care about these. They're the sort of thing that dances around from one unix to the next anyway. The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. These are nice. [1] When the original FSSTND was created I argued in favour of /libexec and /usr/libexec, but lost that debate. I'm less convinced now than I was then, but my main reason for opposing it now is that it is too late to change. Nah - we've always got to be careful about it's too late now syndrome. To think otherwise, is to plot a path to obsolescence. They oughta add /libexec, tho. Symlinks help, especially if you keep developers informed that usage Of those symlinks is deprecated.
Debian, Linux, the FSSTND, the FHS and BSD
(Note: this message is crossposted between two mailing lists - you should probably follow up on only one.) 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. I argued against many of the changes that were proposed, on the grounds such as the disruption that would be caused to the Linux community by moving things or the fact as I saw it that the FSSTND's arrangements were cleaner and that we should not compromise, moving things to messier locations, because BSD had done it that way. I lost this argument, chiefly through a combination of poor politics on my part and the fact that there were more people who seemed willing to make major sacrifices for compatibility with BSD. 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. * /var/lib is renamed to /var/state (yes, all of it). * /var/lib/games is moved to /var/games. * 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. The two good changes that I see are (and they are not minor): * /usr/share exists and is defined. * /opt exists and is defined. I have spent an awful lot of time and energy on the FSSTND mailing list, and I do not have any left with which to further persue this matter there in the face of the very considerable amount of bad feeling which exists. It pains me greatly to say this, given my emotional investment in the work of the FSSTND, but: if the FHS draft is promulgated as it stands I shall not support its adoption by the Debian project. It looks like we (Debian) are going to need /opt, and possibly /usr/share. We can take those parts if we need them. I'm posting this message so that: (a) The rest of the Debian Project can decide what they want to do. If the consensus is that they wish to follow the new standard then I shall be unhappy, of course. I don't know what my reaction would be in terms, for example, of my authorship of dpkg and of the Debian Project policy manual. Disillusionment, I suppose. (b) The newly-renamed FHS group can reconsider - though I doubt that they will. They'll see this as an attempt by me to blackmail them. For the Debian people: the latest draft can be found on tsx-11.mit.edu in /pub/linux/docs/linux-standards/private/fsstnd/. Ian. [1] When the original FSSTND was created I argued in favour of /libexec and /usr/libexec, but lost that debate. I'm less convinced now than I was then, but my main reason for opposing it now is that it is too late to change.
