Subject: RE: Summary: Third-party rc.d scripts
To: Tim Rightnour <root@garbled.net>
From: Frederick Bruckman <fredb@immanent.net>
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.
Frederick