Skip site navigation (1)Skip section navigation (2)
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>