Packages should not Conflict on the basis of duplicate functionality

[Clint Adams <schizo@debian.org>]

   The apparent solution to something like bug#45344 is to have all
the packages providing an identd to conflict with one another.
While reasonable in most cases, this has the horrible side effect
of not letting the administrator have multiple identds on the
system.  What if I have a machine with three IPs bound to its
primary interface and want to run midentd on one, oidentd on
another, and pidentd on the third?  Well, first of all I would
have to replace Debian's inetd with something more configurable,
but then I would be forced to deal with the package manager, which
really should have no business preventing me from having as many
implementations of identd as I like.
   Perhaps identd isn't an example to be taken seriously.  So let's
say that I have a POP server.  I want to have qpopper running on
port 110.  Then I want cucipop running on port 995 through stunnel
for users who want to use SSL.  Then I want to run gnu-pop3d on
a high port for testing purposes since it's brand new and I don't
want to throw it into production without testing it first.  What
happens?  Well, nothing, since all three packages cannot coexist
peacefully.  qpopper has nothing to say about the matter, but
cucipop expressly conflicts with it, in addition to conflicting
with pop3-server, which both it and gnu-pop3d provide.
   These packages don't conflict; they merely provide the same
service.  There is no reason that these three packages cannot
coexist on the same system.  Any namespace overlap can be
solved by alternatives or renaming, as such things are normally
rectified.
   Debian policy should proscribe such inconveniences.