Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
- To: firstname.lastname@example.org
- Cc: 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, 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: Mon, 25 Jan 1999 12:57:51 -0800 (PST)
- Message-id: <199901252057.MAA12660@cesium.transmeta.com>
- In-reply-to: <199901252054.MAA16413@sodium.transmeta.com>
> >> New systems would need to have a /var/spool/mail -> /var/mail symbolic
> >> link for about two years.
> Erik Troan <firstname.lastname@example.org> writes:
> > No, forever. Red Hat is promising an upgrade path for a lot longer then two
> > years -- we've already provided upgradeable distributions for 3.5.
> I said "new systems", not systems that are being upgraded.
> > You seem to be ignoring the upgrade issue. Allowing in-place upgrades
> > necessetates /var/spool/mail to exist in some form.
> I'm not ignoring it, I just don't think it's a problem.
> If today's in-place upgrades don't allow /var/spool/mail to be a
> symbolic link, then they are broken. The same would be true for
> /var/mail on a system that still mounted the spool on /var/spool/mail.
I think interoperability requires that they be compatible as long as
possible, preferrably indefinitely. I would suggest:
1. REQUIRE /var/mail and /var/spool/mail to both exist, and be
2. RECOMMEND future use of /var/mail throughout.
3. DEPRECATE the use of /var/spool/mail.
I don't see a need for abolishing the link /var/spool/mail any time
soon; it has to remain reserved namespace indefinitely anyway.