> 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 preferable means. 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 the matter?
