Subject: Re: post-installation and rc.d enhancements
To: Frederick Bruckman <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
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
> 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. :-)