[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/mailname

On Mon, Mar 25, 2002 at 08:42:56PM -0500, christophe barbé wrote:
> On Tue, Mar 26, 2002 at 12:00:18PM +1100, Matthew Palmer wrote:
> > On Tue, 26 Mar 2002, Santiago Vila wrote:

> > > Yves Arrouye wrote:
> > > > [ about /etc/mailname ].
> > > > But some package should own it yes.

> > > It has never been a requirement that every file in the system
> > > should be owned in the "dpkg -S" sense by some package.

> > However, if a file is deleted that is not owned by any package, then no
> > package should have a problem with that.  I don't think that's the case for
> > /etc/mailname.  I seem to recall having mail sent as 'mjp16@<null>' (yes,
> > entirely literal string) at one point in the dim past, as a result of not
> > having an /etc/mailname.

> > If a package wants a file, it should either own it or depend on a package
> > that does.

> Yes. And is there a good reason for this file to be a special case ?
> It looks like a conffile to me.

Then you should read more about conffiles.

Debian Policy, Appendix E: Configuration file handling

  The easy method is to ship a best-effort configuration in the package,
  and use dpkg's conffile mechanism to handle updates. If the user is
  unlikely to want to edit the file, but you need them to be able to
  without losing their changes, and a new package with a changed version
  of the file is only released infrequently, this is a good approach.

  The hard method is to build the configuration file from scratch in the
  postinst script, and to take the responsibility for fixing any mistakes
  made in earlier versions of the package automatically. This will be
  appropriate if the file is likely to need to be different on each

A file containing a domain portion to be used in email addresses for the 
local system is most *definitely* in the second category ("the file is
likely to need to be different on each system").

The simple lesson to users who are bitten by removing this file is: if
you didn't put it there, don't remove it either unless you're sure you
know what you're doing.  Note that even making this a conffile would not
help a user who blindly removes this file; conffile handling explicitly
(as documented in Policy) does not reinstall files that have been
removed by the local admin.

Every package that uses this file in Debian either creates it directly
if missing, or depends on a package that does.  Anything else is a bug
-- but removing the file and wondering why system behavior changed
is a bug in the user's understanding of how the Debian system works, not 
in the Debian system itself.
Steve Langasek
postmodern programmer

Attachment: pgpoB6K95sBsx.pgp
Description: PGP signature

Reply to: