Subject: RE: Summary: Third-party rc.d scripts
To: Frederick Bruckman <>
From: Tim Rightnour <>
List: tech-pkg
Date: 02/09/2002 14:51:16
On 09-Feb-02 Frederick Bruckman wrote:
> So I'm looking at the form file. You just need to add a line or three
> for each script, and it shows up in "sushi"? If so, then we just handle
> the form file in step "1" above. We could embed the information in the
> package rc.d script itself, or -- here's an idea -- add an
> install_sushi() function, to the package scripts, only.

That was along the lines of what I was thinking.  Problem with that is that if
someone upgrades the OS they lose all those fields.

>> It also might confuse some people, who see "apache" in thier configuration
> file,
>> and turn it on, wondering why it doesn't start or work.
> But you wouldn't want to remove the hook, while leaving the
> "/etc/rc.conf" file unchanged. That could lead to some interesting
> surprises, after the user installed a package that he had deinstalled
> quite a long time ago. Likewise, it makes no sense to remove the default
> entry from "/etc/defaults/rc.{,pkg.}conf, while the active setting
> remains in "/etc/rc.conf".
> The only solution I see, is to add a check to "sushi", so that it grays
> out or otherwise complains about entries whose corresponding rc.d script
> doesn't exist.

I don't think sushi can really do that.  This is where everything start to get
really messy.  Basically you want to remove the lines from defaults, rc.conf,
and the sushi form file.

It would be alot easier if the pkg stuff had it's own rc.conf and
rc.conf.defaults, which it could manipulate without fear of the system being
upgraded and wiped out.  Even without sushi, that would have been a problem.
(at least for defaults)

Tim Rightnour <>
NetBSD: Free multi-architecture OS
NetBSD supported hardware database: