Subject: Re: HEADS UP: RCD_SCRIPTS_EXAMPLEDIR changed to share/examples/rc.d
To: Robert Elz <kre@munnari.OZ.AU>
From: Jeremy C. Reed <email@example.com>
Date: 12/30/2004 15:31:47
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