Re: Bug#504880: Disambiguate "installed" for packages
On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote:
> Jonathan Nieder <email@example.com> writes:
> > Russ Allbery wrote:
> >> I think we should hopefully be close to a final wording now.
> > Indeed! All I have left are copy-edits (patch below).
> Thanks! Applied to my copy.
> >> @@ -5048,7 +5132,7 @@ Provides: mail-transport-agent
> >> Conflicts: mail-transport-agent
> >> Replaces: mail-transport-agent
> >> </example>
> >> - ensuring that only one MTA can be installed at any one
> >> + ensuring that only one MTA can be unpacked at any one
> >> time. See <ref id="virtual"> for more information about this
> >> example.
> >> </sect1>
> > Aside: is this advice right? Maybe we should be encouraging
> > Provides: mail-transport-agent
> > Breaks: mail-transport-agent
> > Replaces: mail-transport-agent
> > instead.
> Policy 11.6 requires that any package providing mail-transport-agent
> install /usr/sbin/sendmail and provide a program called newaliases, and
> hence they really do need Conflicts:
> /etc/aliases is the source file for the system mail aliases (e.g.,
> postmaster, usenet, etc.), it is the one which the sysadmin and
> postinst scripts may edit. After /etc/aliases is edited the program or
> human editing it must call newaliases. All MTA packages must come with
> a newaliases program, even if it does nothing, but older MTA packages
> did not do this so programs should not fail if newaliases cannot be
> found. Note that because of this, all MTA packages must have Provides,
> Conflicts and Replaces: mail-transport-agent control fields.
> The problem with using alternatives here is that the sendmail and
> 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. That prevents
> installing more than one MTA at the same time, which could occasionally be
> useful, but ensures that everything installed is consistent and works
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
Imagine a large red swirl here.