Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related
ports issues)
Richard Coleman
richardcoleman at mindspring.com
Sun Nov 30 21:25:36 PST 2003
Robert Watson wrote:
> 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 at fledge.watson.org Senior Research Scientist, McAfee Research
I think this message sums up the options quite nicely.
I like option 2 the best, with option 3 a close second. I think either
would be an acceptable compromise.
Option 1 abandons the ability for read-only /usr, which many people
like. That and the NFS problems that Robert mentioned should rule this out.
But I like anything over doing nothing (option 4).
Richard Coleman
richardcoleman at mindspring.com
More information about the freebsd-ports
mailing list