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