Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Sergei Kolobov]

On 2003-11-30 at 23:47 -0500, Robert Watson wrote:
> (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.

I think this approach is fine for many installations, but it should be
used as the (only) solution to /etc/rc.d vs. ${LOCALBASE}/etc/rc.d problem.
 
> (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.

This looks like the best approach to me.
 
> (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.

This one reminds me of the /etc/opt in the FHS, although our current
structure with all non-base (ports) files under a common hierarchy is
more logical, IMHO. I do not think we should change that.

> (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. 

No, please do not do that. ;)

> I'm actually leaning towards (2) as being the best solution, as it's easy
> and functional.

I fully agree - I support option 2 as the best approach.

Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20031201/5822f652/attachment.bin