Subject: Re: post-installation and rc.d enhancements
To: Frederick Bruckman <fredb@immanent.net>
From: Alan Barrett <apb@cequrux.com>
List: tech-userlevel
Date: 04/18/2002 16:59:31
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.

I understand "the whole file" to be a single file with configuration for
multiple packages.  I understand "re-install" to mean "overwrite".

> > No!  Please don't do that!
> >
> > People keep old binary packages lying around, and expect to be able to
> > reinstall them later (perhaps to downgrade after a bad experience with
> > a newer version of the package).  The old binary package would not know
> > about the new variables in the monolithic config file.
> 
> Huh? Why would that matter. If an old package rc.d script has no
> knowledge of a particular variable, it'll just ignore it. Except for a
> few odd corners, you're mostly only going to have a single variable
> that matches the name of the script. I'm only talking about a
> monolithic "defaults" file -- the user is expected to copy & paste
> from there to "rc.conf".

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.

> > Other people might want to install binary packages from the NetBSD ftp
> > site as well as their own private packages, but the "official" binary
> > packages will not know about variables needed by the private packages.
> 
> So? You could either source your own defaults file in /etc/rc.conf
> (which would be silly), or you could have a section at the end of your
> rc.conf with a comment, "Local scripts -- These don't have defaults --
> they have to be either "YES", or "NO"".

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.

--apb (Alan Barrett)