> Technical reasons for making the change; > > a. Compatibility with the majority of existing unix systems.
Incompatibility with the majority of Linux systems. Incompatibility with the majority of Linux packages. > b. See a. It can not be stressed enough. If FHS is ever to get OUT > of the Linux camp it's going to have to cause Linux to look more > like other unix systems and less like Linux. Thats an argument for saying "there are these symlinks. We specify no more". Not for changing > c. Removal of the special case for Linux in many public domain/freeware > software, though this should already be handled via paths.h if the > application is written with portability considerations. Those applications are already present > d. BSD based systems basically made this same change over 15 years > ago. It was no real big deal. /usr/spool -> /var/spool, then /var/spool was done by Sun and for very big technical reasons - sharable /usr You still don't have a leg to stand on. --- Now something more productive. These are the points being recycled We've proved: a) People want to put their mail where they like it. b) Where you put mail is application dependant FHS 2.0 has mandated /var/mail, the entire vendor population regards it as unacceptable hassle to change, as does the user base in general. In some environments /var/mail helps compatibility with nonLinux ----------- I'd like to propose that for now the FHS is changed to read "The mail spool area location is undefined. It is guaranteed that both /var/mail and /var/spool/mail point to this mail spool area if the system has a mail spool. The preferred reference name is /var/mail. [Rationale: /var/mail is the only name available on some other modern Unix platforms. /var/spool/mail is the older Linux tradition and needed for compatibility] [Rationale2: The physical location of the mail spool is not relevant to an application and is administrator policy. It is thus left open.] Can everyone live with that and bury the thread Alan