Re: Packages should not Conflict on the basis of duplicate functionality
On Fri, Sep 24, 1999 at 11:13:27AM -0400, Scott K. Ellis wrote:
> Okay, then solve the problem of which one should actually work on the
> standard port? You can't use update-alternatives if the software is
> launched in a different manner. If you have such an advanced setup, it
> isn't really that hard to build it yourself, or use --force.
I do not believe that any network daemon should automatically start
grabbing resources without asking. By installing a package, I only
consent to commiting disk space and the resoureses needed to get it
actually on the disk. Anything beyond that should be asked
Some polite packages do ask nicely whether to use inetd or to start via an
Other ones ask which port to run on or even if to run at all.
Why shouldn't *all* daemon packages ask these questions, and whether to even
run *upon install*?
I do not like the idea of a daemon starting up with a default
configuration that I have not double checked upon installation. I
consider automatically starting with no choice a misfeature.
And as to the idea that if I run a 'complex' system, I should dl the package
and recompile is not a good one. We have not defined 'complex' and
'simple' except trivially; if you do something that isn't possible with
the current tools, then it is complex. We cannot afford that
definition. It would hinder us.
Running multiple daemons providing the same service is reasonable and
expected in a production environment and *even* in the home of an
The real question is not "why not" by "how".
We is confronted with insurmountable opportunities.
-- Walt Kelly, "Pogo"
The Doctor What: Second Baseman http://docwhat.gerf.org/
email@example.com (finger firstname.lastname@example.org for PGP key)