Date: Sun, 30 Nov 2003 23:47:24 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "Maxim M. Kazachek" <stranger@sberbank.sibnet.ru> Cc: Oliver Eikemeier <eik@freebsd.org> Subject: Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues) Message-ID: <Pine.NEB.3.96L.1031130234018.74465G-100000@fledge.watson.org> In-Reply-To: <20031201092813.X355@sbk-gw.sibnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:
> On Sun, 30 Nov 2003, Richard Coleman wrote:
<snip>
For 5.2-RELEASE, I think we should ignore the whole issue and let the
couple of ports that insert things in /etc/rc.d "just do it". We're not
going to find any other solution in time to either close the discussion or
test it properly.
For 5.2-CURRENT, I think we should revisit this issue with one of the
following conclusions winning out, and the rest being discarded as
flame-bait:
(1) Combine / and /usr into a single file system by default, and add
/usr/local/etc/rc.d to the search order, with appropriate hacks to
handle old-style scripts. The devil will be in the bikeshed, but the
implementation is easy, except for the bit where we explain that
NFS-mounted /usr/local won't work too well.
(2) Reevaluate the order at routine points in the boot where new scripts
might now be available (due to file system mounts or whatever).
Essentially "insert the new cards into the deck, and shuffle". This
requires rethinking of our current approach, which assumes a static
order is created once at the start of the boot by rcorder(8). The
devil will be in the big picture *and* the details of the
implementation.
(3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a
new directory that third party applications are allowed to modify
during install, and that will be present for the creation of the
static ordering by rcorder(8) early in the boot. The devil will be in
the bikeshed, but the implementation is easy.
(4) Continue to ignore the issue and let some ports install into /etc/rc.d
and consider them unorthodox, incorrect, but something we can
overlook. The devil isn't here, or at least, if it is, we'll overlook
it.
I'm actually leaning towards (2) as being the best solution, as it's easy
and functional.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031130234018.74465G-100000>