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

[Jonathan Nieder]

(-cc: the bug.  Sorry about that tangent.)

Bill Allombert wrote:

> Another issue is that only one MTA can be listening on port 25 at any time, 
> and Debian
> does not provide a way to prevent two packages to be configured to listen on 
> the same
> port.

That is a good point, and one that I do not think could not be solved
with triggers.  So packages that require an MTA (like fcron) really
need to stop while switching MTAs, or they can find themselves
without a sendmail to talk to (and, in the case of fcron, lose
output from jobs).

Thanks.  Will think more.


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100727151151.gb1...@burratino

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

[Russ Allbery]

Jonathan Nieder  writes:

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

I think what happens in practice in this case is that apt calls dpkg with
some --force-* flag, or at least that's what the messages that I've seen
scroll by in this sort of situation seem to imply.  I agree that it would
be good to have a better way of handling it (although also agree that's a
different bug than this one).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbjl7qy9@windlord.stanford.edu

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

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  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-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100726230555.gb3...@burratino