Russ Allbery wrote:
> Jonathan Nieder <jrnie...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
