[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#504880: Disambiguate "installed" for packages

On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote:
> 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.

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

Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Reply to: