mail-transport-agent (Re: Bug#504880: Disambiguate "installed" for packages)

[Jonathan Nieder <jrnieder@gmail.com>]

Russ Allbery wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Aside: is this advice right?  Maybe we should be encouraging
>
>>  Provides: mail-transport-agent
>>  Breaks: mail-transport-agent
>>  Replaces: mail-transport-agent
>
>> instead.
[...]
> newaliases programs have to match whatever MTA is actually being used,
> since bad things could happen (like losing data) if the alternative points
> to one MTA but a different MTA is actually running.  Alternatives don't
> really provide a good way of making those things line up, so what we've
> historically done is make all the mail-transport-agent providers just ship
> those binaries in those paths and conflict with each other.

Part of the reason I am interested is because it makes switching
between MTAs difficult.  Recently[1] there was some discussion
proposing the following rule:

	Secondly, Replaces allows the packaging system to resolve which
	package should be removed when there is a conflict - see
	Conflicting binary packages - Conflicts, Section 7.4.  This
	usage only takes effect when the two packages do conflict, so
	that the two usages of this field do not interfere with each
	other.

	Conflicts+Replaces should be used only to ensure that obsolete
	packages are removed in favour of new packages.  A package
	should not declare Replaces against any non-obsolete package,
	and it should not declare Replaces against any virtual package
	it itself provides.

That /seems/ to neglect another traditional use of Conflicts+Replaces,
which is to allow switching between relatively important packages that
cannot be installed at the same time.

If we instead take the Conflicts seriously, then switching between MTAs
requires the following sequences of events:

 deconfigure packages that pre-depend or depend on mail-transport-agent
 remove the old mail-transport-agent
 unpack the new mail-transport-agent  
 configure in the appropriate order

This looks like an awfully slow way to accomplish a task that would
probably be dealt with better by triggering on /etc/aliases.  But that
is probably something to propose for squeeze+2 or so.

Thanks for the explanation.

[1] http://lists.debian.org/debian-ctte/2010/05/msg00010.html