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

[Andreas Metzler]

On 2006-11-25 Javier Fernández-Sanguino Peña <jfs at computer.org> wrote:
> 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)

Hello,
No idea. But it does not matter a lot if any package in a *standard*
Debian installation does, it only matters if packages in Debian can
rely on /etc/mailname on being generated by the first package
generating it and if *any* packge at all uses this.

> 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:

No, not only MTAs, any package generating a "From:"-line.
<quote>For example, in this situation the inn package<unquote>
                                          ^^^
Especially stuff generating *usenet* messages. Check e.g knews,
postilion, slrn.

> - 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:

This ignores the fact that packages which are not providing mta can
still generate and send outgoing mail (by smtp). Policy does not limit
the scope of /etc/mailname to MTAs and packages using MTAs (by the
/usr/sbin/sendmail interface).

[...]
> 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.

The point is that it is not just shared among MTAs and packages
depending on MTAs.
cu andreas

-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde