Subject: Re: /usr/pkg/etc/rc.d/*
To: Quentin Garnier <>
From: Michael G. Schabert <>
List: current-users
Date: 03/16/2003 14:38:35
At 11:42 AM +0100 3/16/03, Quentin Garnier wrote:
>Le Sun, 16 Mar 2003 05:14:22 -0500
>Michael G. Schabert a =E9crit :
>>  At 12:23 AM -0500 3/16/03, wrote:
>>  >On Sat, Mar 15, 2003 at 03:01:35PM -0800, Greywolf wrote:
>>  >>  Should /etc/rc.conf by default contain the line:
>>  >>
>>  >>  . /usr/pkg/etc/rc.conf
>>  >>
>>  >>  at its end?
>>  >>
>>  >>  This would roughly complete the root-pkg split.
>>  >
>>  >Is /usr mounted when this would happen?
>>  Moot. If /usr is not mounted, then /usr/pkg/bin is unavailable, so it
>>  wouldn't matter if /usr/pkg/etc isn't there. In other words, if we
>>  did things as they have been suggested (moving the scripts to
>>  /etc/rc.d and using /etc/rc.conf), and /usr were unmounted when rc
>>  was running, no packages would be started since the binaries aren't
>>  there. The scripts are only as good as the binaries that they're
>>  calling.
>rc.d scripts must be in /etc because at the time of rcorder, /usr is not
>mounted (unless a trivial case). Given the dependancies though, /usr is
>mounted when the time comes for those package to run (they will typically
>depend on DAEMON).
>The hack suggested by Greywolf would work (rc.conf is reread by each
>script) but the problem of rcorder will remain, unless we add a rc.d
>script named 'pkg' that will rcorder scripts in /usr/pkg/etc/rc.d. This
>has the drawback of not letting the user precisely define globally the
>order of scripts.

This is somewhat putting the cart before the horse except in special 
circumstances*. There are basically two camps in this proposal.

1) anything in /usr/pkg/etc/rc.d/ should be copied to /etc/rc.d/

2) There should be /usr/pkg/etc/rc.conf which controls scripts that 
reside in /usr/pkg/etc/rc.d/.

But /usr must be mounted for any action to be taken regardlerss of 
the approach, since the action taken still requires /usr/pkg/bin to 
be there.

Approach 1)
Copy/move rc.d files to /etc. Now the files can be read before /usr 
is mounted. However, the binaries that are called in the files are 
still unavailable until after /usr is mounted. So you must take care 
to construct the REQUIRES so that rcorder doesn't execute the script 
until after /usr is mounted.

Approach 2)
Rc doesn't even know about the scripts until after /usr is mounted. 
=46ine, since nothing could be done anyway.

You're advocating approach 1, as that will still let rcorder 
determine precise order. With approach 2, you would essentially have 
an rcorder for the base distribution and an rcorder for packages, to 
be run later. I don't really see that as the drawback that you do, 
since the users who actually wish to "precisely define globally the 
order of scripts" are in no way impeded from still using approach 
1...they'll just have an empty /usr/pkg/etc/rc.conf. They aren't 
encumbered by doing anything more than they would be otherwise, but 
as a whole, the system will be much more elegant. As it is, we have 
rc.conf, rc.lkm, and rc.local. If you don't want to use 
/usr/pkg/etc/rc.conf, then adding an /etc/rc.pkg would (1) still 
"feel right", (2) keep the same interface. This rc.pkg would be like 
rc.conf in that it would be looking for foo=3DYES as opposed to the 
rc.local looking for the actual commands or script names. It would 
still not allow its options to be rcordered until after /usr is 
mounted, since that is where the rc.d files with the order info would 

Just my thoughts,

* Packages are installed (by default) in /usr/pkg/ except those for 
X11 and certain special cases like standalone-tcsh. X11 binaries 
should not be called by rc, but rather by xdm, xinit, etc. The 
special cases that install outside /usr could easily also simply use 
the "regular" /etc/rc.conf and /etc/rc.d/.
Bikers don't *DO* taglines.