Debian Bug report logs - #42052
[ACCEPTED 2/4/01] /var/mail and /var/spool/mail

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: submit@bugs.debian.org

Subject: [PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 27 Jul 1999 23:31:13 -0700

Package: debian-policy
Version: 3.0.1

On Tue, Jul 27, 1999 at 02:39:36PM -0500, Manoj Srivastava wrote:
>  >> This way, people would be free to move /var/spool/mail/* to /var/mail/*
>  >> at their discretion, but this is never done automatically by the system.
> 
>  Joseph> That was the point of the suggestion.  There was actually a
>  Joseph> bug to this effect against policy suggesting we do this, but
>  Joseph> I closed it when it seemed FHS was going to lose /var/mail
>  Joseph> since there were complaints about it.
> 
>         Sounds like a plan. Could you reopen this proposal, then, and
>  we can make this a part of policy 3.0.X?

Okay,

I propose that we create a safe migration path between /var/spool/mail and
/var/mail.

The base-files package should implement the following:
  * If /var/mail does not exist but /var/spool/mail does (standard
    configuration today), a symlink /var/mail -> /var/spool/mail should be
    created.
  * If /var/mail does exist but /var/spool/mail does not, a symlink
    /var/spool/mail -> /var/mail should be created.
  * If /var/mail and /var/spool/mail are both directories, Something Is
    Really Screwed and the installation should fail, telling the user to
    clean up the disaster.  =>  (lost or mangled mail is potentially a
    disaster and we should not risk an automated solution..)

To do this I suggest we ammend policy first by replacing all existing
instances of /var/spool/mail with /var/mail and then changing the second
paragraph of section 5.6 which currently reads

   The mail spool is /var/spool/mail and the interface to send a mail
   message is /usr/sbin/sendmail (as per the FHS). The mail spool is part
   of the base system and not part of the MTA package.

to the following:

   The mail spool is /var/mail and the interface to send a mail message is
   /usr/sbin/sendmail (as per the FHS).  The mail spool is part of the
   base system and any package requiring use øf /var/mail must declare
   dependency on base-files (>= #BASEFILESVER#).


Also, a new section should be inserted after section 3.1.2 containing the
following:

  3.1.3 The system mail spool

   While the FHS mandates the mail spool be accessable as /var/mail, it is
   important to retain compatibility with older packages and locally
   compiled programs.  Packages using the mail spool should use /var/mail
   and declare dependency on base-files (>= #BASEFILESVER#).


There's some redundancy in that, but I think it's warranted I think.  If
someone else thinks they can do a better job with the changes to the
policy, feel free to offer.  =>

I think it's best to leave the nitty-gritty handling of making sure both
exist and one is a symlink to the other to the base-files maintainer since
that's all under the scope of the base-files post or preinst and doesn't
concern anything else.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
Software is like sex, it's better when it's free.     -- Linus Torvalds

Message #10 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Gordon Matzigkeit <gord@fig.org>

To: Joseph Carter <knghtbrd@debian.org>

Cc: 42052@bugs.debian.org

Subject: Re: Bug#42052: [PROPOSAL] /var/mail and /var/spool/mail

Date: 28 Jul 1999 10:51:21 -0600

>>>>> Joseph Carter writes:
[...]

 JC> I propose that we create a safe migration path between
 JC> /var/spool/mail and /var/mail.

I second this proposal.

FWIW, I was hoping that an identical solution would be proposed for
/usr/doc vs. /usr/share/doc, but the catch is that several packages
have already moved to /usr/share/doc.  Perhaps if we could get them to
declare dependencies on a newer base-files, we could solve the problem
without too much sludge.

-- 
 Gordon Matzigkeit <gord@fig.org>  //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)

Message #15 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Gordon Matzigkeit <gord@fig.org>

Cc: 42052@bugs.debian.org

Subject: Re: Bug#42052: [PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 28 Jul 1999 10:13:35 -0700

[Message part 1 (text/plain, inline)]

On Wed, Jul 28, 1999 at 10:51:21AM -0600, Gordon Matzigkeit wrote:
> [...]
> 
>  JC> I propose that we create a safe migration path between
>  JC> /var/spool/mail and /var/mail.
> 
> I second this proposal.
> 
> FWIW, I was hoping that an identical solution would be proposed for
> /usr/doc vs. /usr/share/doc, but the catch is that several packages
> have already moved to /usr/share/doc.  Perhaps if we could get them to
> declare dependencies on a newer base-files, we could solve the problem
> without too much sludge.

I'm opposed to this solution for /usr/share/doc simply because it's a
cop-out.  In the case of the mail spool it's necessary, but in the case of
doc directories?  The only thing I can see right offhand that REALLY needs
docs to be in one dir is apache's /doc symlink which many argue is a
security risk as it is.

Everything else could adapt like everything else has to manpages for
example.  In proposed solutions so far, any symlinks between directories
for /usr/doc are temporary.  /var/mail and /var/spool/mail are a permanent
condition.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
* dark has changed the topic on channel #debian to: Later tonight: After
  months of careful refrigeration, Debian 2.0 is finally cool enough to
  release.

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: Joseph Carter <knghtbrd@debian.org>, 42052@bugs.debian.org

Subject: Re: Bug#42052: [PROPOSAL] /var/mail and /var/spool/mail

Date: Sat, 31 Jul 1999 21:35:31 -0700

Joseph Carter wrote:
> I propose that we create a safe migration path between /var/spool/mail and
> /var/mail.

Seconded. Thanks for an excellent migration path.

-- 
see shy jo

Message #25 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Joseph Carter <knghtbrd@debian.org>, 42052@bugs.debian.org

Subject: Re: Bug#42052: [PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 3 Aug 1999 14:39:37 +0200 (CET)

On Tue, 27 Jul 1999, Joseph Carter wrote:

> [...]
> To do this I suggest we ammend policy first by replacing all existing
> instances of /var/spool/mail with /var/mail and then changing the second
> paragraph of section 5.6 which currently reads
> 
>    The mail spool is /var/spool/mail and the interface to send a mail
>    message is /usr/sbin/sendmail (as per the FHS). The mail spool is part
>    of the base system and not part of the MTA package.
> 
> to the following:
> 
>    The mail spool is /var/mail and the interface to send a mail message is
>    /usr/sbin/sendmail (as per the FHS).  The mail spool is part of the
>    base system and any package requiring use øf /var/mail must declare
>    dependency on base-files (>= #BASEFILESVER#).
> 
> 
> Also, a new section should be inserted after section 3.1.2 containing the
> following:
> 
>   3.1.3 The system mail spool
> 
>    While the FHS mandates the mail spool be accessable as /var/mail, it is
>    important to retain compatibility with older packages and locally
>    compiled programs.  Packages using the mail spool should use /var/mail
>    and declare dependency on base-files (>= #BASEFILESVER#).

I second this proposal, but please change the word "dependency"
by "Pre-Dependency" (otherwise I would formally object ;-).

Rationale: base-files (>=whatever) must be unpacked and *configured*
before *any* package using /var/mail is *unpacked*, because the symlink
/var/mail -> /var/spool/mail will be handled in base-files' postinst.

[ Try to think what happens if an important program start to access
  /var/mail without /var/mail being there yet ].

BTW: The footnote pointed out by Antti-Juhani should be reworded also.
(Yes, this is the footnote saying we should still follow /var/spool/mail
regardless of what FHS says).

Thanks.

-- 
 "9646ee6e65c45b4fb4034ce347d9e7f0" (a truly random sig)

Message #30 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Santiago Vila <sanvila@unex.es>

Cc: 42052@bugs.debian.org

Subject: Re: Bug#42052: [PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 3 Aug 1999 08:32:57 -0700

[Message part 1 (text/plain, inline)]

On Tue, Aug 03, 1999 at 02:39:37PM +0200, Santiago Vila wrote:
> >    While the FHS mandates the mail spool be accessable as /var/mail, it is
> >    important to retain compatibility with older packages and locally
> >    compiled programs.  Packages using the mail spool should use /var/mail
> >    and declare dependency on base-files (>= #BASEFILESVER#).
> 
> I second this proposal, but please change the word "dependency"
> by "Pre-Dependency" (otherwise I would formally object ;-).
> 
> Rationale: base-files (>=whatever) must be unpacked and *configured*
> before *any* package using /var/mail is *unpacked*, because the symlink
> /var/mail -> /var/spool/mail will be handled in base-files' postinst.

Obviously and I support this addition.


> [ Try to think what happens if an important program start to access
>   /var/mail without /var/mail being there yet ].
> 
> BTW: The footnote pointed out by Antti-Juhani should be reworded also.
> (Yes, this is the footnote saying we should still follow /var/spool/mail
> regardless of what FHS says).

I oppose the footnote.  There is no reason why packages cannot and should
not use /var/mail right now (pending postinst of a working base-files that
will create it)


The argument that some of the dselect methods do not properly handle
package ordering is IMO a bad reason not to do something.  If anything,
they should be fixed.  Same goes for dpkg and symlinks.

In any event unlike the symlinks issue, there is no harm that is not
already clearly documented in using /var/mail.  You might have to run a
few extra installs or configures but if your dselect method is that broken
you're going to have to do that anyway---and already have been doing it
anyway.  New users will never see these broken things.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<Crow_> hmm, is there a --now-dammit option for exim?

[Message part 2 (application/pgp-signature, inline)]

Message #35 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: Joseph Carter <knghtbrd@debian.org>, 42052@bugs.debian.org

Cc: Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 4 Aug 1999 09:33:46 +1000

[Message part 1 (text/plain, inline)]

On Tue, Aug 03, 1999 at 08:32:57AM -0700, Joseph Carter wrote:
> > I second this proposal, but please change the word "dependency"
> > by "Pre-Dependency" (otherwise I would formally object ;-).
> > Rationale: base-files (>=whatever) must be unpacked and *configured*
> > before *any* package using /var/mail is *unpacked*, because the symlink
> > /var/mail -> /var/spool/mail will be handled in base-files' postinst.
> Obviously and I support this addition.

I'm confused. No packages install things into /var/spool/mail or /var/mail
directly, do they? Nor can I see why they'd want to use this as part of
their preinst or even postinst. Neither exim nor mutt include /var/anything
in their dpkg -L output.

Why does /var/mail have to exist before those packages are unpacked?

Before they're actually *executed*, I could believe, but that only
requires an ordinary dependency, no?

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Anthony Towns <aj@azure.humbug.org.au>

Cc: 42052@bugs.debian.org, Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 4 Aug 1999 00:48:08 -0700

[Message part 1 (text/plain, inline)]

On Wed, Aug 04, 1999 at 09:33:46AM +1000, Anthony Towns wrote:
> > > I second this proposal, but please change the word "dependency"
> > > by "Pre-Dependency" (otherwise I would formally object ;-).
> > > Rationale: base-files (>=whatever) must be unpacked and *configured*
> > > before *any* package using /var/mail is *unpacked*, because the symlink
> > > /var/mail -> /var/spool/mail will be handled in base-files' postinst.
> > Obviously and I support this addition.
> 
> I'm confused. No packages install things into /var/spool/mail or /var/mail
> directly, do they? Nor can I see why they'd want to use this as part of
> their preinst or even postinst. Neither exim nor mutt include /var/anything
> in their dpkg -L output.
> 
> Why does /var/mail have to exist before those packages are unpacked?
> 
> Before they're actually *executed*, I could believe, but that only
> requires an ordinary dependency, no?

MTA's are started immediately on configuration of the package.

If you do not start the program in postinst (say a MUA) all you need is a
dependency.  If the program gets started before that, it has to pre-depend
or deal gracefully with the not-yet-installed case.

It could always fork a watch process that waits for dpkg to finish, but
that would be bad for other reasons.  (remember that xaw-wrappers bug that
caused configuration of other packages to not happen until you got a fixed
version?)  If you start it in postinst, pre-dep base-files.  I probably
should add post an ammended proposal addressing all this shouldn't I?

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<kira> is a surgical war where you go give the foreign troops nose jobs?

[Message part 2 (application/pgp-signature, inline)]

Message #45 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Ruud de Rooij <ruud@master.debian.org>

To: Joseph Carter <knghtbrd@debian.org>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 4 Aug 1999 03:19:58 -0500

On Wed, Aug 04, 1999 at 12:48:08AM -0700, Joseph Carter wrote:

> MTA's are started immediately on configuration of the package.
> 
> If you do not start the program in postinst (say a MUA) all you need is a
> dependency.  If the program gets started before that, it has to pre-depend
> or deal gracefully with the not-yet-installed case.

postinsts are executed in dependency order.

So what "not-yet-installed case" are you talking about?

	- Ruud de Rooij.
-- 
ruud de rooij | ruud@ruud.org | http://ruud.org

Message #50 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Ruud de Rooij <ruud@master.debian.org>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 4 Aug 1999 01:38:27 -0700

[Message part 1 (text/plain, inline)]

On Wed, Aug 04, 1999 at 03:19:58AM -0500, Ruud de Rooij wrote:
> > MTA's are started immediately on configuration of the package.
> > 
> > If you do not start the program in postinst (say a MUA) all you need is a
> > dependency.  If the program gets started before that, it has to pre-depend
> > or deal gracefully with the not-yet-installed case.
> 
> postinsts are executed in dependency order.
> 
> So what "not-yet-installed case" are you talking about?

If base-files' postinst will always be run before the postinst for a MTA
depending on it, then a pre-dep is not needed.  It was my understanding
that dpkg could get confused this way and run things in the wrong order.
If we can be sure of this and it is guaranteed to be so, a pre-dep is not
needed.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<Culus> dhd:  R you part of the secret debian overstructure?
<dhd> no. there is no secret debian overstructure.
<CosmicRay> although, now that somebody brought it up, let's start one
            :-)
<Knghtbrd> CosmicRay - why not, sounds like a fun way to spend the
           afternoon =D

[Message part 2 (application/pgp-signature, inline)]

Message #55 received at 42052@bugs.debian.org (full text, mbox, reply):

From: ruud@ruud.org (Ruud de Rooij)

To: Joseph Carter <knghtbrd@debian.org>

Cc: 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 04 Aug 1999 10:47:54 +0200

On 1999/08/04, Joseph Carter wrote:

> If base-files' postinst will always be run before the postinst for a MTA
> depending on it, then a pre-dep is not needed.  It was my understanding
> that dpkg could get confused this way and run things in the wrong order.
> If we can be sure of this and it is guaranteed to be so, a pre-dep is not
> needed.

From the Packaging manual, section 8.2:

     Thus `Depends' allows package maintainers to impose an order in which
     packages should be configured.

     `dpkg' will not configure packages whose dependencies aren't
     satisfied.

If dpkg does run postinsts in the wrong order, then we might just as well 
turn all depends fields into pre-depends.

	- Ruud de Rooij.
-- 
ruud de rooij | ruud@ruud.org | http://ruud.org

Message #60 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Ruud de Rooij <ruud@ruud.org>

Cc: 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 4 Aug 1999 02:18:25 -0700

[Message part 1 (text/plain, inline)]

On Wed, Aug 04, 1999 at 10:47:54AM +0200, Ruud de Rooij wrote:
> > If base-files' postinst will always be run before the postinst for a MTA
> > depending on it, then a pre-dep is not needed.  It was my understanding
> > that dpkg could get confused this way and run things in the wrong order.
> > If we can be sure of this and it is guaranteed to be so, a pre-dep is not
> > needed.
> 
> >From the Packaging manual, section 8.2:
> 
>      Thus `Depends' allows package maintainers to impose an order in which
>      packages should be configured.
> 
>      `dpkg' will not configure packages whose dependencies aren't
>      satisfied.
> 
> If dpkg does run postinsts in the wrong order, then we might just as well 
> turn all depends fields into pre-depends.

Okay, you're right.  See what all this arguing does to one's brain?
Depends it is, since Pre-depends is clearly not needed.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
acme-cannon (3.1415) unstable; urgency=low

  * Added safety to prevent operator dismemberment, closes: bug #98765,
    bug #98713, #98714.
  * Added manpage. closes: #98725.

  -- Wile E. Coyote <genius@debian.org>  Sun, 31 Jan 1999 07:49:57 -0600

[Message part 2 (application/pgp-signature, inline)]

Message #65 received at 42052@bugs.debian.org (full text, mbox, reply):

From: cwitty@newtonlabs.com (Carl R. Witty)

To: Anthony Towns <aj@azure.humbug.org.au>

Cc: 42052@bugs.debian.org, Joseph Carter <knghtbrd@debian.org>, Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: 04 Aug 1999 12:16:51 -0700

Anthony Towns <aj@azure.humbug.org.au> writes:

> --ncSAzJYg3Aa9+CRW
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Aug 03, 1999 at 08:32:57AM -0700, Joseph Carter wrote:
> > > I second this proposal, but please change the word "dependency"
> > > by "Pre-Dependency" (otherwise I would formally object ;-).
> > > Rationale: base-files (>=whatever) must be unpacked and *configured*
> > > before *any* package using /var/mail is *unpacked*, because the symlink
> > > /var/mail -> /var/spool/mail will be handled in base-files' postinst.
> > Obviously and I support this addition.
> 
> I'm confused. No packages install things into /var/spool/mail or /var/mail
> directly, do they? Nor can I see why they'd want to use this as part of
> their preinst or even postinst. Neither exim nor mutt include /var/anything
> in their dpkg -L output.
> 
> Why does /var/mail have to exist before those packages are unpacked?

Others have explained that this is probably not necessary for MTA's.
However, it still seems necessary for MUA's.  On a multi-user system,
any unpacked MUA could possibly get executed while the package is
unconfigured, and before base-files is configured.

Carl Witty
cwitty@newtonlabs.com

Message #70 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: "Carl R. Witty" <cwitty@newtonlabs.com>, 42052@bugs.debian.org

Cc: Joseph Carter <knghtbrd@debian.org>, Santiago Vila <sanvila@unex.es>

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Thu, 5 Aug 1999 09:32:11 +1000

On Wed, Aug 04, 1999 at 12:16:51PM -0700, Carl R. Witty wrote:
> > On Tue, Aug 03, 1999 at 08:32:57AM -0700, Joseph Carter wrote:
> > > > I second this proposal, but please change the word "dependency"
> > > > by "Pre-Dependency"
> > Why does /var/mail have to exist before those packages are unpacked?
> Others have explained that this is probably not necessary for MTA's.
> However, it still seems necessary for MUA's.  On a multi-user system,
> any unpacked MUA could possibly get executed while the package is
> unconfigured, and before base-files is configured.

However, that MUA would presumably get run by a non-root user, who couldn't
create a subdirectory with /var, which isn't world-writable.

And while that may cause the MUA to do "weird" things (like read the user's
mail via /var/spool/mail, or die saying "can't find your mail"), for an
unconfigured package, this doesn't seem unreasonable.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Message #75 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Joseph Carter <knghtbrd@debian.org>

Cc: 42052@bugs.debian.org

Subject: Re: #42052: [PROPOSAL] /var/mail and /var/spool/mail

Date: Thu, 5 Aug 1999 18:01:07 +0200 (CET)

On Tue, 3 Aug 1999, Joseph Carter wrote:

> > BTW: The footnote pointed out by Antti-Juhani should be reworded also.
> > (Yes, this is the footnote saying we should still follow /var/spool/mail
> > regardless of what FHS says).
> 
> I oppose the footnote. [...]

Sorry for the bad wording...

I meant that the footnote should probably be *removed* :-)

Thanks.

-- 
 "1931ddc45002a3c61bf0db1196c201db" (a truly random sig)

Message #80 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Thu, 5 Aug 1999 18:46:33 +0200 (CET)

On Thu, 5 Aug 1999, Anthony Towns wrote:

> On Wed, Aug 04, 1999 at 12:16:51PM -0700, Carl R. Witty wrote:
> > > On Tue, Aug 03, 1999 at 08:32:57AM -0700, Joseph Carter wrote:
> > > > > I second this proposal, but please change the word "dependency"
> > > > > by "Pre-Dependency"
> > > Why does /var/mail have to exist before those packages are unpacked?
> > Others have explained that this is probably not necessary for MTA's.
> > However, it still seems necessary for MUA's.  On a multi-user system,
> > any unpacked MUA could possibly get executed while the package is
> > unconfigured, and before base-files is configured.
> 
> However, that MUA would presumably get run by a non-root user, who couldn't
> create a subdirectory with /var, which isn't world-writable.
> 
> And while that may cause the MUA to do "weird" things (like read the user's
> mail via /var/spool/mail, or die saying "can't find your mail"), for an
> unconfigured package, this doesn't seem unreasonable.

It would be unreasonable that we claim that we can upgrade the system
"in place" without it being true.

Pre-Depends are absolutely needed for MUAs.

It is 100% certain that *every* MTA is stopped in the postrm? If so, I
will not mind that policy is reworded so that it says "Pre-Depends for
MUAs, Depends for MTAs".

Thanks.

-- 
 "0d3d17f3e045810164c5d1fb545ae4d3" (a truly random sig)

Message #85 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: Santiago Vila <sanvila@unex.es>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Fri, 6 Aug 1999 12:58:17 +1000

[Message part 1 (text/plain, inline)]

On Thu, Aug 05, 1999 at 06:46:33PM +0200, Santiago Vila wrote:
> > > > Why does /var/mail have to exist before those packages are unpacked?
> > > Others have explained that this is probably not necessary for MTA's.
> > > However, it still seems necessary for MUA's.  On a multi-user system,
> > > any unpacked MUA could possibly get executed while the package is
> > > unconfigured, and before base-files is configured.
> > However, that MUA would presumably get run by a non-root user, who couldn't
> > create a subdirectory with /var, which isn't world-writable.
> > And while that may cause the MUA to do "weird" things (like read the user's
> > mail via /var/spool/mail, or die saying "can't find your mail"), for an
> > unconfigured package, this doesn't seem unreasonable.
> It would be unreasonable that we claim that we can upgrade the system
> "in place" without it being true.
> Pre-Depends are absolutely needed for MUAs.

How so?

MUAs that are currently executing will continue to work (the mail isn't
getting moved or anything), by the time the MTA is configured, it'll
work, and MTA's being executed sometime between being unpacked and
configured will at worst fail in an obvious, harmless way.

Must all packages work completely correctly even in unconfigured state?

> It is 100% certain that *every* MTA is stopped in the postrm? If so, I
> will not mind that policy is reworded so that it says "Pre-Depends for
> MUAs, Depends for MTAs".

And again, even if the MTA *isn't* stopped, it will simply keep using
/var/spool/mail, blithely unaware that someone's making a /var/mail
link, and that it'll soon be restarted as a new binary that uses that
link.

Your failure case here seems to be an admin deliberately killing the MTA
and restarting it while it's unconfigured and its dependencies aren't met
(which admittedly is actually reasonably likely if you're running your
MTA from inetd). But even then, at least for exim, it simply means mail
will be spooled instead of delivered with an error like;

1999-08-06 12:54:44 11Ca9c-000060-00 == aj@distress.localnet T=local_delivery defer (2): No such file or directory: creating lock file hitching post /var/spool/mail/aj.lock.distress.localnet.37aa4e74.00000176

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

[Message part 2 (application/pgp-signature, inline)]

Message #90 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@azure.humbug.org.au>

To: Santiago Vila <sanvila@unex.es>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Fri, 6 Aug 1999 13:11:49 +1000

On Fri, Aug 06, 1999 at 12:58:17PM +1000, Anthony Towns wrote:
> MUAs that are currently executing will continue to work (the mail isn't
> getting moved or anything), by the time the MTA is configured, it'll
                                              ^^^
> work, and MTA's being executed sometime between being unpacked and
            ^^^
> configured will at worst fail in an obvious, harmless way.

I did, of course, mean MUA here both times.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Message #95 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Anthony Towns <aj@azure.humbug.org.au>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 10 Aug 1999 13:23:01 +0200 (CET)

On Fri, 6 Aug 1999, Anthony Towns wrote:

> [...]
> Must all packages work completely correctly even in unconfigured state?

This is a very good question, indeed.

I withdraw my suggestion to use Pre-Depends for this.

[ Still, we have to be very sure that *every* MTA is stopped in the postrm
before doing this change in policy ].

Thanks.

-- 
 "07e0a39c83e9d4d163f44bf6bd016ca2" (a truly random sig)

Message #100 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ian@davenant.greenend.org.uk>

To: 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 17 Aug 1999 20:18:45 +0100 (BST)

On Tue, 27 Jul 1999, Joseph Carter wrote:
> To do this I suggest we ammend policy first by replacing all existing
> instances of /var/spool/mail with /var/mail and then changing the second
> paragraph of section 5.6 which currently reads

I object to this proposed change on the following grounds:

There are no reasons for us to change.  The FHS made a gratuitous
change in this area.  If someone wants to install software that really
does require /var/mail to exist they can make the symlink themselves.

There are reasons for us not to change: it is hard to do right, as the
discussion has shown, and if we get it wrong we risk making people's
mail systems fall over or even losing mail.

Ian.

Message #105 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 18 Aug 1999 12:56:23 +0200 (CET)

On Tue, 17 Aug 1999, Ian Jackson wrote:

> On Tue, 27 Jul 1999, Joseph Carter wrote:
> > To do this I suggest we ammend policy first by replacing all existing
> > instances of /var/spool/mail with /var/mail and then changing the second
> > paragraph of section 5.6 which currently reads
> 
> I object to this proposed change on the following grounds:
> 
> There are no reasons for us to change.  The FHS made a gratuitous
> change in this area.  If someone wants to install software that really
> does require /var/mail to exist they can make the symlink themselves.
> 
> There are reasons for us not to change: it is hard to do right, as the
> discussion has shown, and if we get it wrong we risk making people's
> mail systems fall over or even losing mail.

IMHO, the discussion has not shown it is hard to do it right.

The proposal is to use /var/mail for *new* systems (those installed
from base2_2.tgz) and keep /var/spool/mail for old systems.

There will be no automatic "mv".

[ Note that I'm not particularly disappointed that someone objects this
proposal, I think we could well wait for FHS 2.1 to be official before
going any further ].

Thanks.

-- 
 "76553449e9cb6d42366f37208092f565" (a truly random sig)

Message #110 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Ian Jackson <ian@davenant.greenend.org.uk>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 18 Aug 1999 20:17:53 -0700

[Message part 1 (text/plain, inline)]

On Tue, Aug 17, 1999 at 08:18:45PM +0100, Ian Jackson wrote:
> > To do this I suggest we ammend policy first by replacing all existing
> > instances of /var/spool/mail with /var/mail and then changing the second
> > paragraph of section 5.6 which currently reads
> 
> I object to this proposed change on the following grounds:
> 
> There are no reasons for us to change.  The FHS made a gratuitous
> change in this area.  If someone wants to install software that really
> does require /var/mail to exist they can make the symlink themselves.
> 
> There are reasons for us not to change: it is hard to do right, as the
> discussion has shown, and if we get it wrong we risk making people's
> mail systems fall over or even losing mail.

Creating a symlink is not hard.  It does not lose mail.  It does not harm
the system.

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<Knghtbrd> xtifr - beware of james when he's off his medication  =>

[Message part 2 (application/pgp-signature, inline)]

Message #115 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: Santiago Vila <sanvila@unex.es>, 42052@bugs.debian.org

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Wed, 18 Aug 1999 20:24:37 -0700

[Message part 1 (text/plain, inline)]

On Wed, Aug 18, 1999 at 12:56:23PM +0200, Santiago Vila wrote:
> > There are reasons for us not to change: it is hard to do right, as the
> > discussion has shown, and if we get it wrong we risk making people's
> > mail systems fall over or even losing mail.
> 
> IMHO, the discussion has not shown it is hard to do it right.
> 
> The proposal is to use /var/mail for *new* systems (those installed
> from base2_2.tgz) and keep /var/spool/mail for old systems.

Actually, /var/spool/mail shall be kept on new systems as well for
backwards compatibility--it'll just be a symlink.  The only reason to
actually make it a directory on new systems with a backwards compatibile
symlink is to illustrate that a change has happened.  That and by
including support for it being a directory in base-files, the admin need
never worry about putting it there and having base-files wig out on them
for setting it up that way.


> There will be no automatic "mv".
> 
> [ Note that I'm not particularly disappointed that someone objects this
> proposal, I think we could well wait for FHS 2.1 to be official before
> going any further ].

FHS 2.1 includes /var/mail, but says it may be a symlink if need be.

So essentially Ian is trying to kill the proposal before FHS 2.1 has a
chance to be published and recommend this sort of approach.  Wonderful.

Ahh, how appropriate can a sig get?

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<Davide> how bout a policy policing policy with a policy for changing the
         police policing policy

[Message part 2 (application/pgp-signature, inline)]

Message #120 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Joseph Carter <knghtbrd@debian.org>, 42052@bugs.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>

Subject: Re: Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

Date: Fri, 20 Aug 1999 19:38:02 +0200 (CET)

On Wed, 18 Aug 1999, Joseph Carter wrote:

> On Wed, Aug 18, 1999 at 12:56:23PM +0200, Santiago Vila wrote:
> > [ Note that I'm not particularly disappointed that someone objects this
> > proposal, I think we could well wait for FHS 2.1 to be official before
> > going any further ].
> 
> FHS 2.1 includes /var/mail, but says it may be a symlink if need be.
> 
> So essentially Ian is trying to kill the proposal before FHS 2.1 has a
> chance to be published and recommend this sort of approach.  Wonderful.

I forgot to mention that I *am* a little bit disappointed by the reasoning
given by Ian to kill the proposal, specially, that "FHS is wrong".

Ian, why do you dislike /var/mail for new systems and /var/spool/mail
for old systems? Eventually, we will have to support both, since we
aim for FHS compliance.

Maybe you want a careful release-by-release plan, something like this?:

1. A new base-files which support /var/mail is uploaded to potato.
2. *After* potato is released, we make policy to follow FHS, which says
   that packages should reference /var/mail internally. Packages doing so
   should depend on the base-files in potato.

Why do you say this may not be done right?

Thanks.

-- 
 "295667c0f74b4d3779334eaf98012a62" (a truly random sig)

Message #125 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joseph Carter <knghtbrd@debian.org>

To: 42052@bugs.debian.org

Subject: /var/spool/mail

Date: Mon, 6 Sep 1999 12:14:37 -0700

[Message part 1 (text/plain, inline)]

I figured since it actually seems like there are no major outstanding
objections to this proposal that I probably should rewrite it taking into
account everything said till now.

The general idea:

1.  We cannot just make use of /var/spool/mail illegal right now.
2.  New packages may use /var/spool/mail only if they declare dependency
    on a version of base-files which creates it.
3.  For the purposes of least-surprise upgrades, a system without
    /var/mail will have a symlink created from /var/spool/mail to it.
4.  For the purposes of maximum compatibility, new installations will
    include /var/mail as a directory, but /var/spool/mail will be
    maintained as a symlink.  The installation should be updated to create
    this by default, and base-files should make sure the compatibility
    symlink exists to prevent mail loss.



Transition plan:

Packages using /var/spool/mail should be deprecated immediately, but
remain legal.  The policy group shall review the situation periodically
and, taking into consideration issues such as number and complexity of
packages not following new policy, make the use of /var/spool/mail illegal
some point in the future at their discretion.  Any bug reports necessary
will be filed with important severity at that time.

For historical reasons, compatibility with /var/spool/mail will always be
maintained.



Policy changes (better wordings welcome):

Second paragraph of 5.6 which currently reads:

   The mail spool is /var/spool/mail and the interface to send a mail
   message is /usr/sbin/sendmail (as per the FHS). The mail spool is part
   of the base system and not part of the MTA package.

should be changed to:

   The mail spool is /var/mail and the interface to send a mail message is
   /usr/sbin/sendmail (as per the FHS).  Use of /var/spool/mail is still
   permitted, but has been deprecated.  [reference to 3.1.3 added below]


A new section 3.1.3 should be inserted into policy:   

  3.1.3 The system-wide mail directory

   The system-wide mail directory is /var/mail.  This directory is part of
   the base system and should not owned by any particular mail agents.
   The use of /var/spool/mail is deprecated, but still permitted.  To
   maintain partial upgrade compatibility, packages using /var/mail should
   declare dependency on base-files (>= #BFVER#).



How's that?  Does it cover everything?  Should a second paragraph under
3.1.3 be added talking about both always existing and all that?  I think
those details should be worked out in the base-files postinst and in
base.tgz since they are the only two packages that should even come close
to messing with it.  Seconds?  Issues left unresolved?

-- 
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<Culus> Ben: Do you solumly swear to read you debian email once a day and
        do not permit people to think you are MIA?
<Ben> Culus: i do so swear

[Message part 2 (application/pgp-signature, inline)]

Message #128 received at 42052-submitter@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 43529-submitter@bugs.debian.org, 26995-submitter@bugs.debian.org, 33076-submitter@bugs.debian.org, 34610-submitter@bugs.debian.org, 35510-submitter@bugs.debian.org, 37254-submitter@bugs.debian.org, 39831-submitter@bugs.debian.org, 41829-submitter@bugs.debian.org, 41902-submitter@bugs.debian.org, 42052-submitter@bugs.debian.org, 42358-submitter@bugs.debian.org, 42477-submitter@bugs.debian.org, 42907-submitter@bugs.debian.org, 43483-submitter@bugs.debian.org, 43651-submitter@bugs.debian.org, 43724-submitter@bugs.debian.org, 43757-submitter@bugs.debian.org, 43928-submitter@bugs.debian.org, 44922-submitter@bugs.debian.org, 45318-submitter@bugs.debian.org, 46516-submitter@bugs.debian.org, 46522-submitter@bugs.debian.org, 47438-submitter@bugs.debian.org, 48045-submitter@bugs.debian.org, 13353-submitter@bugs.debian.org, 32263-submitter@bugs.debian.org, 37999-submitter@bugs.debian.org, 38703-submitter@bugs.debian.org, 39299-submitter@bugs.debian.org, 39398-submitter@bugs.debian.org, 39830-submitter@bugs.debian.org, 40742-submitter@bugs.debian.org, 40766-submitter@bugs.debian.org, 40767-submitter@bugs.debian.org, 40934-submitter@bugs.debian.org, 41113-submitter@bugs.debian.org, 41121-submitter@bugs.debian.org, 41729-submitter@bugs.debian.org, 42554-submitter@bugs.debian.org, 42870-submitter@bugs.debian.org, 43077-submitter@bugs.debian.org, 45307-submitter@bugs.debian.org, 45406-submitter@bugs.debian.org, 45561-submitter@bugs.debian.org, 48247-submitter@bugs.debian.org

Subject: Your policy proposal

Date: Tue, 26 Oct 1999 01:33:10 +0100 (BST)

You have submitted a proposed modification to the Debian Policy.  I
would be most grateful if you could check on the status of your
proposal (at http://www.debian.org/Bugs/db/pa/ldebian-policy.html) and
change the title/severity/forwarded status to indicate its present
status, in anticipation of a forthcoming policy revision.

Instructions on the scheme used can be found in
/usr/doc/debian-policy/proposal.text.gz if you are using a new policy
package, and if not, then check out
http://www.debian.org/~srivasta/policy/.

To change the status of a report in the BTS, email
control@bugs.debian.org with one or more lines like the following:
retitle 12345 [ACCEPTED 10/10/99] Allow foobar in section 9.9.9
forwarded 12345 debian-policy@lists.debian.org
severity 12345 normal

You can finish the list of commands with the line:
thanks

Thanks for the help!

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg

Message #133 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 42052@bugs.debian.org

Subject: Bug#42052: /var/spool/mail and /var/mail

Date: Tue, 26 Oct 1999 11:39:06 +0100 (BST)

We spent a lot of time on this list thrashing out the /var/spool/mail
vs. /var/mail issue.  It would be a shame if it came to nothing due to
a lack of seconds.  Please check up this final proposal (included
below) and second it if you think it appropriate.

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg


I figured since it actually seems like there are no major outstanding
objections to this proposal that I probably should rewrite it taking into
account everything said till now.

The general idea:

1.  We cannot just make use of /var/spool/mail illegal right now.
2.  New packages may use /var/spool/mail only if they declare dependency
    on a version of base-files which creates it.
3.  For the purposes of least-surprise upgrades, a system without
    /var/mail will have a symlink created from /var/spool/mail to it.
4.  For the purposes of maximum compatibility, new installations will
    include /var/mail as a directory, but /var/spool/mail will be
    maintained as a symlink.  The installation should be updated to create
    this by default, and base-files should make sure the compatibility
    symlink exists to prevent mail loss.



Transition plan:

Packages using /var/spool/mail should be deprecated immediately, but
remain legal.  The policy group shall review the situation periodically
and, taking into consideration issues such as number and complexity of
packages not following new policy, make the use of /var/spool/mail illegal
some point in the future at their discretion.  Any bug reports necessary
will be filed with important severity at that time.

For historical reasons, compatibility with /var/spool/mail will always be
maintained.



Policy changes (better wordings welcome):

Second paragraph of 5.6 which currently reads:

   The mail spool is /var/spool/mail and the interface to send a mail
   message is /usr/sbin/sendmail (as per the FHS). The mail spool is part
   of the base system and not part of the MTA package.

should be changed to:

   The mail spool is /var/mail and the interface to send a mail message is
   /usr/sbin/sendmail (as per the FHS).  Use of /var/spool/mail is still
   permitted, but has been deprecated.  [reference to 3.1.3 added below]


A new section 3.1.3 should be inserted into policy:

  3.1.3 The system-wide mail directory

   The system-wide mail directory is /var/mail.  This directory is part of
   the base system and should not owned by any particular mail agents.
   The use of /var/spool/mail is deprecated, but still permitted.  To
   maintain partial upgrade compatibility, packages using /var/mail should
   declare dependency on base-files (>= #BFVER#).



How's that?  Does it cover everything?  Should a second paragraph under
3.1.3 be added talking about both always existing and all that?  I think
those details should be worked out in the base-files postinst and in
base.tgz since they are the only two packages that should even come close
to messing with it.  Seconds?  Issues left unresolved?

--
Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE

Message #138 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Alexander Koch <efraim@argh.org>

To: 42052@bugs.debian.org

Subject: Re: Bug#42052: var/spool/mail and /var/mail

Date: Tue, 26 Oct 1999 11:15:26 +0000

On Tue, 26 October 1999 11:39:06 +0100, Julian Gilbey wrote:
> We spent a lot of time on this list thrashing out the /var/spool/mail
> vs. /var/mail issue.  It would be a shame if it came to nothing due to
> a lack of seconds.  Please check up this final proposal (included
> below) and second it if you think it appropriate.

Was that a second by you? ;-)
I also second this proposal.

The change would have to be in the bootdiscs first, right?

Alexander

Message #143 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Wichert Akkerman <wichert@liacs.nl>

To: Alexander Koch <efraim@argh.org>, 42052@bugs.debian.org

Subject: Re: Bug#42052: var/spool/mail and /var/mail

Date: Tue, 26 Oct 1999 14:04:49 +0200

[Message part 1 (text/plain, inline)]

Previously Alexander Koch wrote:
> The change would have to be in the bootdiscs first, right?

base-files.

Wichert.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@liacs.nl                    http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

[Message part 2 (application/pgp-signature, inline)]

Message #148 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, 42052@bugs.debian.org

Subject: Re: Bug#42052: var/spool/mail and /var/mail

Date: Tue, 26 Oct 1999 10:28:44 -0400

On Tue, Oct 26, 1999 at 11:39:06AM +0100, Julian Gilbey wrote:
> We spent a lot of time on this list thrashing out the /var/spool/mail
> vs. /var/mail issue.  It would be a shame if it came to nothing due to
> a lack of seconds.  Please check up this final proposal (included
> below) and second it if you think it appropriate.

It looks good.  It looks like appropriate links are implemented as well.

-- 
Raul

Message #153 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Joel Klecker <jk@espy.org>

To: 42052@bugs.debian.org

Subject: Re: Bug#42052: var/spool/mail and /var/mail

Date: Tue, 26 Oct 1999 22:05:10 -0700

At 10:28 -0400 1999-10-26, Raul Miller wrote:
>It looks good.  It looks like appropriate links are implemented as well.

I put some symlinking code into the libc6 postinst because 
/usr/include/paths.h defines _PATH_MAILDIR to /var/mail, and there is 
quite a bit of software about that uses that macro to find where the 
mail spool is.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>

Message #164 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 42052@bugs.debian.org

Subject: Bug#45052: [OLD PROPOSAL] /var/mail and /var/spool/mail

Date: Mon, 26 Feb 2001 22:52:29 +0000

I was looking through old proposals, and saw this one.  It discusses
changing policy to refer to /var/mail instead of /var/spool/mail.  The
discussion sort of hung, but in the meantime, events have overtaken
it: both base-files and libc6 essentially do the following:

if /var/spool/mail is a directory, then symlink /var/mail to it
otherwise /var/mail is a directory, and symlink /var/spool/mail to it

In fact, base-files follows the FHS and makes /var/mail the mail spool
on new systems.  But more than that, the FHS specifically does not
require /var/mail to be the mail directory itself; it may be a
symlink, typically to /var/spool/mail.

So this proposal really ought to go in to policy, as it represents
current practice.

Here is the suggested change:

Section 12.6: the para which currently reads:

   The mail spool is `/var/spool/mail' and the interface to send a mail
   message is `/usr/sbin/sendmail' (as per the FHS).  ...

should be changed to:

   The mail spool is `/var/mail' and the interface to send a mail
   message is /usr/sbin/sendmail (as per the FHS).  On older systems,
   the mail spool may be physically located in /var/spool/mail, but
   all access to the mail spool should be via the /var/mail symlink.

A new section 10.1.3 should be inserted into policy:

  10.1.3 The system-wide mail directory

   The system-wide mail directory is /var/mail.  This directory is
   part of the base system and should not owned by any particular mail
   agents.  The use of the old location /var/spool/mail is deprecated,
   even though the spool may still be physically located there.  To
   maintain partial upgrade compatibility for systems which have
   /var/spool/mail as their physical mail spool, packages using
   /var/mail > must depend on either libc6 (>= 2.1.3-13), or on
   base-files (>= 2.2.0), or on later versions of either one of these
   packages.

Comments, seconds anyone?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

         Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
       Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Message #169 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: <42052@bugs.debian.org>

Subject: Re: Bug#42052: Bug#45052: [OLD PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 27 Feb 2001 01:49:43 +0100 (CET)

On Mon, 26 Feb 2001, Julian Gilbey wrote:

> Section 12.6: the para which currently reads:
>
>    The mail spool is `/var/spool/mail' and the interface to send a mail
>    message is `/usr/sbin/sendmail' (as per the FHS).  ...
>
> should be changed to:
>
>    The mail spool is `/var/mail' and the interface to send a mail
>    message is /usr/sbin/sendmail (as per the FHS).  On older systems,
>    the mail spool may be physically located in /var/spool/mail, but
>    all access to the mail spool should be via the /var/mail symlink.
>
> A new section 10.1.3 should be inserted into policy:
>
>   10.1.3 The system-wide mail directory
>
>    The system-wide mail directory is /var/mail.  This directory is
>    part of the base system and should not owned by any particular mail
>    agents.  The use of the old location /var/spool/mail is deprecated,
>    even though the spool may still be physically located there.  To
>    maintain partial upgrade compatibility for systems which have
>    /var/spool/mail as their physical mail spool, packages using
>    /var/mail > must depend on either libc6 (>= 2.1.3-13), or on
>    base-files (>= 2.2.0), or on later versions of either one of these
>    packages.

I second this.

Message #174 received at 42052@bugs.debian.org (full text, mbox, reply):

From: Nicolás Lichtmaier <nick@debian.org>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, 42052@bugs.debian.org

Subject: Re: Bug#42052: Bug#45052: [OLD PROPOSAL] /var/mail and /var/spool/mail

Date: Tue, 27 Feb 2001 00:43:06 -0300

> Comments, seconds anyone?

 I second this.

Message #185 received at 42052-done@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: 42052-done@bugs.debian.org, 83977-done@bugs.debian.org, 85503-done@bugs.debian.org, 86436-done@bugs.debian.org, 87233-done@bugs.debian.org

Subject: debian-policy_3.5.4.0_i386.changes INSTALLED

Date: Mon, 30 Apr 2001 09:25:19 +0100

Installing:
debian-policy_3.5.4.0.tar.gz
  to pool/main/d/debian-policy/debian-policy_3.5.4.0.tar.gz
fhs.txt byhand
fhs-2.1.html.tar.gz byhand
policy.txt.gz byhand
perl-policy.txt.gz byhand
debian-policy_3.5.4.0.dsc
  to pool/main/d/debian-policy/debian-policy_3.5.4.0.dsc
menu-policy.txt.gz byhand
mime-policy.txt.gz byhand
virtual-package-names-list.txt byhand
policy.pdf.gz byhand
debconf_specification.txt.gz byhand
policy.html.tar.gz byhand
libc6-migration.txt byhand
debian-policy_3.5.4.0_all.deb
  to pool/main/d/debian-policy/debian-policy_3.5.4.0_all.deb
policy.ps.gz byhand
Changes: debian-policy (3.5.4.0) unstable; urgency=low
 .
  * [ACCEPTED 2/4/01] /var/mail and /var/spool/mail  closes: Bug#42052
  * [AMENDMENT 26/04/2001] include Perl Policy       closes: Bug#83977
  * Also incorporates all the improvements that Julian has made to to the
    grammar and flow of the policy manual. The following are mostly
    Julian's fixes:
  * Fixed the confusing self referential language.   closes: Bug#85503
  * Correct ambiguous kanguage about declaring build dependencies.
                                                     closes: Bug#86436
  * Improved the woding of the footnote about shlibdeps.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

         Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
       Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Send a report that this bug log contains spam.