On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote: > Jonathan Nieder <jrnie...@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.
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. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727131222.gq15...@yellowpig
