Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- To: tytso@MIT.EDU (Theodore Y. Ts'o)
- Cc: email@example.com, tytso@MIT.EDU, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Subject: Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- From: "H. Peter Anvin" <email@example.com>
- Date: Tue, 26 Jan 1999 17:37:53 -0800 (PST)
- Message-id: <199901270137.RAA14733@cesium.transmeta.com>
- In-reply-to: <199901270131.UAA04092@dcl> from "Theodore Y. Ts'o" at "Jan 26, 99 08:31:54 pm"
> Most Mail User Agents for standard Unix systems look in /var/mail/<user>
> for the user's mailbox. So if qmail is switching to ~/Mailbox, then
> they have to solve the problem for all of the various MUA's out there,
> and that is really qmail's and mutt's problem. I assume someone in that
> community must have thought about the problem, since people generally
> don't react well when they're told that they can't use their favorite
> mail reader because some new mail system has decided to use a different
> mailbox convention.
> So maybe any standard should not say something about the mail spool dir?
Actually, it might be worthwhile to specify that if environment
variable MAILBOX exists, then MUAs need to honour it?
> Well, the problem is what happens if a third-party wants to ship a mail
> user agent? If how you get mail on a system is a distribution-local
> thing, that means that only the distribution-provided mail readers have
> a chance of working correctly. The whole point of the LSB effort was to
> allow this kind of third-party application provider to be able to work
> across different Linux systems, and not have certain applications that
> only work on RedHat systems, but not Debian systems, or vice versa.