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

[Richard Coleman]

Matthias Andree wrote:

> Richard Coleman <richardcoleman at mindspring.com> writes:
> 
> 
>>But that kinda defeats the purpose of RCNG.  One of the best features of
>>RCNG is that it makes it easier to add/delete applications from the
>>system.  Not using it for this purpose reduces its utility.
>>
>>Let's not let the typical BSD traditionalism get in the way of using
>>RCNG for what it's designed.  Don't get me wrong.  I'm not advocating
>>Linux-style integration of packages/ports.  But this seems fairly
>>harmless.
> 
> 
> Ports belong into /usr/local, not into /etc. There should be some hook
> that allows port start scripts to run before some base system scripts,
> and if Oliver's two-staged "reevaluate" approach supports this with /
> and /usr in separate partitions, then why not take his suggestion?
> 
> There's nothing that prevents RCNG from stretching out its fangs to
> /usr/local/etc/rc*, in fact, hier(7) encourages that.
> 
> If I get the picture right, what's suggested is that after mounting
> local file systems, the RC order is re-evaluated, and again after
> mounting remote file systems ("diskless"). This would allow the system
> to gradually complete its /etc/rc* picture.
> 
> Another idea would be to use unionfs or something to keep
> /usr/local/etc/rc.d in the root partition for real, and when it's
> shadowed by the actual /usr/local or /usr mount, punch a hole so you can
> look at the rootfs with unionfs or something. I'd like Oliver's
> suggestion better though.
> 

I guess I'm not really arguing for putting the startup scripts for ports 
in /etc/rc.d (contradicting what I said earlier).  But I do think that 
RCNG/rcorder needs to be extended to handle ports.  And it needs to be 
done in a more comprehensive fashion than just adding special hooks for 
backend databases.  The multiple rcorder evaluation method you mention 
sounds like a good place to start.

The unionfs idea is also interesting.  But I doubt many people trust it 
enough to use it for this purpose.  It's a shame really, but that's 
another discussion.

Richard Coleman
richardcoleman at mindspring.com