Subject: Summary: Third-party rc.d scripts
To: None <firstname.lastname@example.org>
From: Amitai Schlair <email@example.com>
Date: 02/07/2002 23:48:37
Here's my attempt at a summary of the problems we're trying to solve, and
the proposed solutions.
1) Some people want all rc.d scripts in /etc/rc.d.
Lubomir pointed out that pkgsrc can already accommodate an admin's
preference for where to install rc.d scripts, and can install them
there automatically. Frederick suggested that we can enable this
behavior by default if we append foo=NO to /etc/defaults/rc.pkg.conf
(which gets sourced by /etc/defaults/rc.conf).
pkgsrc can be taught to stash an rc.d script somewhere safe before
overwriting it (/var/backups?).
2) Some people want some rc.d scripts in places other than /etc/rc.d.
Luke suggested a pair of rc.conf variables to add options to rcorder
at startup and shutdown, including additional rc.d directories. If you
have additional rc.d dirs on the root fs, this lets you use them.
If you have additional rc.d dirs not on the root fs, there are no easy
answers. You can either put the rc.d scripts somewhere on your root fs,
or run a separate pass of rcorder later in the boot process. Things are
configurable enough, at least, that you can tweak to your needs.
3) Some people want to be able to install multiple versions of a package.
This doesn't work yet. Making it work is going to be hard. If we
eventually have to change how we handle rc.d scripts to accommodate
multiple simultaneous package versions, this won't significantly alter
the overall difficulty. "We'll cross that bridge when we get to it."
Please point out if I have any of this wrong, or if there are any serious
unaddressed issues. If we can agree that the sum of these ideas is a
strong improvement, then we can put them to work!
(Of course, I agree that controlling the entire system with package tools
is the real answer, and it's fantastic that this is shaping up in -current.
But pkgsrc also supports older releases and other operating systems.)