Re: Bug#504880: Disambiguate "installed" for packages
Jonathan Nieder <jrnieder@gmail.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
together.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: