Subject: RE: Summary: Third-party rc.d scripts
To: Tim Rightnour <>
From: Frederick Bruckman <>
List: tech-pkg
Date: 02/09/2002 18:43:16
On Sat, 9 Feb 2002, Tim Rightnour 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.

I thought I already suggested that we keep the defaults up to date. By
that I mean, when someone commits a new package rc.d script, he's
obligated to add the information for "defaults/rc.pkg.conf" to
/usr/src/etc/defaults/rc.pkg.conf". In fact, it looks like
"share/sushi/rcconf/form" could be generated from
defaults/rc.pkg.conf, or perhaps both could be generated from a more
suitable meta-form, so the committer just has to run a little script.
A user whose defaults are out of date would run practically the same
script at package install time. That leaves one issue...

> > 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.

With that, if you have any interesting flags, you lose. How am I
supposed to remember all this stuff:

nasd=YES                nasd_flags="-aa"
xfstt=YES               xfstt_flags="--dir /usr/local/share/fonts/TrueType"
upslog=YES              upslog_flags="smartups@localhost /var/log/ups 60"

? ;-)

Maybe the form-file-generating-script could check for orphaned
rcvar's, and add a `(not installed)' to the end of the description?

> 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)

For rc.conf, that's trivial: "/etc/defaults/rc.conf" is sourced near
the beginning of "/etc/rc.conf", so you just source
"/etc/defaults/rc.pkg.conf" at the beginning of that, and you have
your defaults for "/etc/rc" and for "sushi" automatically.