On Fri, 31 Dec 2004, Robert Elz wrote:

> On the other hand, if I am explicitly installing apache, or cups, or ...
> surely I want to use the thing, why else would I be installing it?

Many things are installed because they are dependencies -- and you may not
know. For example, cups as a service may not be needed, but it is a
dependency of ghostscript-esp which I use for ggv and groff. I don't need
cups running on most systems. (Probably we should split out the cups
libraries into a new package.)

Or I often run sshd from inetd. So I don't want to use the rc.d script to
start it automatically.

I also have slapd, slpd, and slurpd. I don't use them at all. I am not
even using openslp or openldap (knowingly). I now see that cups (that I
don't use) depends on openslp. And openldap is a dependency of kdebase
(used by my wife). We don't need an LDAP service running.

Nevertheless, I don't care if the rc.d scripts are automatically installed
and on these systems, they are automatically installed because the
packages were built with PKG_RCD_SCRIPTS=YES. I just don't want them to
start the service automatically at next boot.

(I keep some of the other comments below.)

> (Of course, I may be just building binary packages, but if I'm that
> kind of user, I probably know how to set an option to prevent auto-start
> of the new server).

> This is a very good argument for auto-start - if I need a package,
> but didn't know I need it, then I'm not going to know that I'm supposed
> to start it, am I?   So, if it is important enough to be a dependency
> of something, then it really should be installed, and started, without
> me having to do a thing - otherwise the package that I really wanted isn't
> going to function properly, is it?    (Aside: I know there are packages
> that have bad dependencies like this, but they're just bugs, like broken
> rc.d scripts, which should be fixed - we shouldn't be considering the
> presence of bugs when we're deciding what is the correct approach, we
> just fix those as we find them).

 Jeremy C. Reed

 	  	 	 BSD News, BSD tutorials, BSD links
	  	 	 http://www.bsdnewsletter.com/