Subject: Re: post-installation and rc.d enhancements
To: Frederick Bruckman <fredb@immanent.net>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-userlevel
Date: 04/18/2002 10:45:36
On Thu, 18 Apr 2002, Frederick Bruckman wrote:

> On Thu, 18 Apr 2002, Alan Barrett wrote:
>
> > On Thu, 18 Apr 2002, Frederick Bruckman wrote:
> > > On Thu, 18 Apr 2002, Alan Barrett wrote:
> > > > On Wed, 17 Apr 2002, Frederick Bruckman wrote:
> > > > > we don't have to edit the file -- we can just re-install the whole file
> > > > > with each package that has an rc.d script.
>
> > If I reinstall an old binary package, then it would overwrite my
> > existing copy of the "defaults" file, thus destroying the defaults for
> > newer packages.
>
> Oh. Now I understand what you mean.

Doh! That's what I get for not reading all the messages. :-)

> > I want my private packages to use the same framework as NetBSD packages.
> > If all NetBSD packages are supposed to add their variables to a single
> > monolithic "defaults" file, but my private packages are not allowed to
> > do that, then my private packages are not using the same infrastructure.
>
> Got it.
>
> Ok, David Brownlee suggested (in another forum), that we add a
> pre-amble to package rc.d scripts for "sushi". So how about if we do
> this:
>
> 1) Every rc.d script (package, base, local) gets a pre-amble that
>    includes the comment, and the type of variable (yes/no, flags,
>    arbitrary string).

I think that's the only way we'll keep all of this under control. :-)

> 2) We create a utility, to live in "/usr/sbin", that generates
>    "/etc/defaults/rc.conf" and "/etc/defaults/sushi-rcconf" from
>    the information embedded in the scripts in "/etc/rc.d", and run
>    it from "pkg_add", or base system "make install" (it'll have to
>    be a host tool) or pkgsrc "make install" (when necessary)?

I like the idea. My vote though would be to have different defaults for
the different namespaces. the pkg and local ones would need to be rebuilt
on the fly on a machine, but the "system" one, I think, should be built as
part of the system build and not changed on a running system. That way you
get a set of scripts *and* the defaults for those scripts together, and
you leave them alone until you next upgrade. :-)

Take care,

Bill