Bug#400292: exim4-config: Should remove /etc/mailname if created automatically

[Javier Fernández-Sanguino Peña]

On Sat, Nov 25, 2006 at 09:47:21AM +0100, Andreas Metzler wrote:
> On 2006-11-25 Javier Fernández-Sanguino Peña <jfs at computer.org> wrote:
> > Package: exim4-config
> > Version: 4.63-10
> > Priority: wishlist
> 
> > Exim4-config generates /etc/mailname automatically on postinst, based on the
> > information provided by the user. It fails, however, to remove this
> > configuration file if the package is purged from the system.
> 
> That is because /etc/mailname is a shared configuration file. Multiple
> installed programs are using it, removing just *one* of them (exim)
> must not break the others.

What other programs use this file (in a standarda Debian installation)
besides the standard mail-transport-agent (i.e exim4)?  In my system's
configuration files I only see emacs using this as well as PostgreSQL's
reusing that information for SSL certificate generation in postinst (although
it behaves properly if /etc/mailname does not exist)

AFAIK only different MTAs should use this file and they should behave
properly if the file has been removed due to a purge, as policy 11.6
dictates. Ie, this should be ok:

- exim4-config gets installed and configured (/etc/mailname gets created)
- exim4-config gets purged (automatically generated /etc/mailname gets
  removed as well as the debconf info)
(some time later...)
- alternate MTA (sendmail, postfix, whatever) gets installed 
  --> The alternate MTA should create (on the basis of policy 11.6)
      /etc/mailname as it does not exist in the system

This is perfectly compatible with:

- exim4-config gets installed and configured (/etc/mailname gets created)
[ an admin installs an alternate mail-transport-agent ]
- exim4-config gets removed (/etc/mailname does *not* get removed) due to
  conflicts
- alternate MTA (sendmail, postfix, whatever) gets installed and reuses
  existing /etc/mailname created by exim4-config

In order to prevent breakage from exim4-config being (later on) purged the
postrm script would "just" have to check if an alternative
mail-transport-agent which might be using /etc/mailname is installed.

If there is no mail-transport-agent when exim4-config is purge it might be
sensible to remove /etc/mailname if it has been created by exim4-config and
has not been changed by the local administrator.

> [...]
> > IMHO, exim4-config should remove /etc/mailname if it can ascertain (through
> > it's checksum) that *he* (and not the admin) created the file. That would
> > make it possible to fix the above situation by purging the package and
> > reinstalling.
> 
> I do not think exim should ever remove this file. The actual breakage
> you encontered needs to be fixed in a different way.

Ok. And that way is?

> cu and- I would suggest closing this bug on the basis of
>         policy 11.6 -reas

From my reading of policy 11.6 what I'm suggesting is perfectly compatible
(if implemented properly, which might be tricky) with having a shared
configuration file across mail-transport-agents in Debian.

Regards

Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20061125/f78669f1/attachment.pgp