Re: Packages should not Conflict on the basis of duplicate functionality
> No, this is silly. When you install a package, it is for use. If you
> don't intend to use it, why install it?
Perhaps you can explain where this idea comes from.
Of course, if I want to evaluate a daemon, I can --unpack the package
into /usr/local/testfun and manually enable it, evaluate it, and then
rm -r it. Sure, that's possible. And I can also compile it myself
from dsc and munge the install scripts. Or I can build it from
pristine source and stick it in /usr/local. So clearly nothing is
preventing me from reaching my desired ends even if it prevents the
But I install packages I don't intend to use. On certain systems
I'll install tcsh or csh. I have no intention of using them
(this is aside from any package that might require a csh provider),
but there is the potential for a user to want tcsh there sometime
in the future, and if he is not clueful to get it on his own,
he'll be okay because it's there. Having a shell package
going and changing users' shells on install would be horrific,
though I doubt anyone would dispute that.
There are daemons that can be run legitimately by a user on high
ports. Let's say you have a system where you let people run
web servers in user space. Luckily, roxen and apache don't
conflict with one another, so you can easily have both available
for users to use, and edit the configs so that neither of them
run on port 80 or any other system port. The daemons are being used;
they're just not being used in the "standard configuration."
On the downside, one cannot reasonably assume that if one installs
both packages that roxen will grab port 80 on bootup.
If you have packages conflict, then yes, you can be pretty certain
that the pop server you've installed is the one that will be grabbing
port 110 on all IPs, because any other pop server has been removed.
So if the consensus is that "debconf should handle it," why don't
we stop the flaming and whining and figure out the logistics of