Bug#362852: Undeclared conflicts: pathname conflict at usr/share/man/man8/sendmail.8.gz between hula-mta, exim4-base

[Justin Pryzby]

On Sat, Apr 22, 2006 at 12:55:31PM +0200, Marc Haber wrote:
> On Sun, Apr 16, 2006 at 10:08:47AM +0200, Andreas Metzler wrote:
> > On 2006-04-16 Justin Pryzby <justinpryzby at users.sourceforge.net> wrote:
> > > Package: hula-mta,exim4-base
> > > Severity: serious
> > 
> > > The etch release policy states that:
> > 
> > > | http://release.debian.org/etch_rc_policy.txt
> > > |       If two packages cannot be installed together, one must list
> > > |       the other in its "Conflicts:" field.
> > 
> > > Both hula-mta and exim4-base include the pathname
> > > usr/share/man/man8/sendmail.8.gz, but neither of them declare an
> > > appropriate "Conflicts:", which is not allowed.
> > [...]
> > 
> > hula-mta Provides/Conflicts/Replaces mail-transport-agent, which makes
> > this an exim4 bug.
> 
> Agreed.
> 
> > It was introduced in 4.60-2 with
> > 
> >   * move man pages from daemon packages to exim4-base, add lintian
> >     and linda overrides to allow daemon packages not to contain man pages.
> 
> Disagreed. If hula-mta provides mail-transport-agent, then exim4-base
> should explicitly conflict with hula-mta. We have the infrastructure
> to automatically conflict with packages that provide m-t-a, and the
> arguments given in the thread following
> http://lists.alioth.debian.org/mailman/private/pkg-exim4-devel/2003-November/001023.html
> (sorry, pkg-exim4-devel archives are non-public, you need to subscribe
> to be able to see the archives) are still valid in my opinion.
So I subscribed to the list and read the thread.

> Why is conflicting with hula-mta a non-sufficient fix?
Why are you going to the trouble of dynamically updating a longer
Conflicts line?  Provide+Conflict+Replace on m-t-a means that you
never have you update for this ever again, but *not* doing so pretty
much guarantees that you'll periodically get an rc bug filed; for
example, everytime someone introduces a new MTA package.

But I'm sure I'm also not seeing the reason for the proposed
complexity :)

> I find it a bad idea to have the man pages in two daemon packages.
Well, this seems to be encouraged, although I don't think its actually
a good thing..  lintian will warn for binary-without-manpage if the
manpage is in some -common package being depended on, last I knew.  Is
this really the source of the complexity ??

Justin