Use of rcorder for local rc.d/*.sh scripts

[JM]

J.R. Oldroyd wrote:

>On Jun 14, 10:27, Brooks Davis wrote:
>  
>
>>On Tue, Jun 14, 2005 at 09:47:32AM -0400, J.R. Oldroyd wrote:
>>
>>    
>>
>>>A. NOW:
>>>	/etc/rc.d	rcordered with "foo" run in subshell and
>>>			"foo.sh" sourced
>>>	local dirs	"foo.sh" run in subshell from localpkg
>>>			in alphabetical order
>>>
>>>B. SOON:
>>>	/etc/rc.d	rcordered with "foo" run in subshell and
>>>			"foo.sh" sourced
>>>	local dirs	"[0-9]foo.sh" scripts are run in a subshell
>>>			first, then "[^0-9]foo.sh" and executable
>>>			"[^0-9]foo" scripts run rcordered and run in
>>>			subshells; "foo.xyz" (e.g., ".sample") ignored?
>>>	ACTION required of port maintainers: NONE
>>>      
>>>
>>One concern I have here is what does first mean?  It seems like we may
>>need to run as early as immediatly after mountcritremote which does
>>change the order a bit and would require a new rc script, something like
>>localpkg-early.
>>
>>    
>>
>I meant first in localpkg.  Or in a localpkg-early script, but I don't
>see the need for an extra script.
>
>
>  
>
>>I'm not quite sure about the exclusions for rcorder.  The *.* exclusion
>>seems like an easy way to avoid *.sh, *.sample, *.orig, *.bak, etc.  I'm
>>not sure what the point of the [^0-9] is though, it would seem that the
>>logical migration path would be for users to add appropriate dependency
>>tags to their scripts and set a ports Makefile variable to cause the .sh
>>to be stripped when installing on appropriate versions of FreeBSD.
>>Removing the ### bits could be done after the flagday.
>>
>>    
>>
>We need to pin this down.  The goal is to exclude junk files.
>If "*.*" is the simplest pattern that does this, great; if not, we
>need a more explicit list such as "*.bak *.orig *.sample" etc.
>
>I would prefer to see (in the final "C." version) that the ONLY
>things allowed in the local rc.d dirs are "foo.sh" files which are
>sourced and "foo" files which are run in a subshell, so as to be
>consistent with /etc/rc.d.  I.e., in the intermediate "B." version,
>anything that is identifiably not this needs to generate a warning.
>
>Are we in agreement that the intermediate "B." versions should not
>break anything and should not require any changes by port maintainers?
>
>
>  
>
>>I'd be strongly tempted to require the documented rcorder pattern be
>>matched by the script in addition to the other exclustions.  We should
>>have egrep at this point so that should be easy.
>>
>>    
>>
>Working, still, on the basis of the intermediate version not requiring
>any changes from port maintainers in order to preserve existing
>functionality, but accepting that we do want to allow maintainers
>to access the new functionality if they indicate it, here's what
>I'm now thinking: we only want to require the use of keywords
>or tag checking if a port maintainer wants to have a "foo.sh" file
>sourced.
>
>If we're not changing /etc/rc and adding the transition functionality
>in localpkg, the transition localpkg will have to:
>
>	process local scripts [0-9]*.sh (in order to preserve
>		current behavior)
>
>		- warn and don't run non-executable files
>
>		- warn and don't run files named "*.sample",
>		  "*.bak", "*.orig" etc
>
>		- warn (suggesting name change) but do run (in
>		  subshell), files named "[0-9]*.sh"
>
>	rcorder and process all the remianing local scripts
>		(rcorder will include non-tagged files at the
>		end of its sorted list, so these are included here
>		too):
>
>		- warn and don't run non-executable files
>
>		- warn and don't run files named "*.sample",
>		  "*.bak", "*.orig" etc
>
>		- warn (suggesting name change) but do run (in
>		  subshell) files named "[^0-9]*.sh" without
>		  new RC_SUBR keyword
>
>		- quietly run (as sourced file) files named
>		  "[^0-9]*.sh" which have new RC_SUBR keyword
>		  (but note that we're in localpkg here, not
>		  /etc/rc so sourcing not quite the same, unless
>		  we do move this functionality into /etc/rc now)
>
>		- quietly run (in subshell) all other files with
>		  rcorder tags
>
>		- warn and don't run any remaining files
>  
>
shouldn't rcorder be run through /usr/local/etc/rc.d before it searches 
for and executes *.sh files?  perhaps mimic the current /etc/rc.d 
mechanism where a piece of rcorder includes "local package 
initialization" (which could be potentially renamed to "starting legacy 
.sh scripts" that runs as a part of rcorder...  basically nesting a 
mirror image of rcorder within the main rcorder that runs through 
/etc/rc.d... this is the only suggestion i have with my limited 
knowledge of rc scripts.  if it sounds dumb just disregard >.>

but i would think that you would want to put more emphasis on change, 
and executing rcorder scripts first would help to ensure this. 

>I don't think we need to require checking for a keyword in files
>named "foo".  If we've identified a proper exclusion list and checked
>for rcorder tags on "foo" files, we're not going to be running any
>"foo" files which are junk.  I dislike the idea of obliging port
>maintainers to add temporary keywords which have to be removed
>later; the above only requires this for functionality not currently
>available.
>
>On the flag day, the final version would be to remove the localpkg
>script and go to the modified /etc/rc which I posted last week.
>Since by then, there should no longer be any junk files, and
>foo/foo.sh semantics will be the same as /etc/rc.d, so that version
>of /etc/rc should work as proposed.
>
>
>  
>
>>I'd like to whine about any files that aren't run, probalby in localpkg.
>>It's fairly easy to do and would provide a push to get rid of the
>>various .sample bits.
>>
>>    
>>
>Agreed - see above.
>
>
>  
>
>>>C. AT FUTURE FLAGDAY:
>>>	/etc/rc.d+local	rcordered with "foo" run in subshell and
>>>			"foo.sh" sourced; "foo.xyz" files now treated
>>>			as "foo"
>>>	ACTION required of port maintainers:
>>>			- add rcorder tags to all scripts
>>>			- rename "foo.sh" to "foo" unless sourced
>>>			  behavior is desired
>>>      
>>>
>>I think we should be able to automate this via USE_RC_SUBR and/or
>>RC_ORDER.
>>
>>    
>>
>
>I'm worried that using these keywords as the control to install
>files/foo.sh.in as rc.d/foo makes it hard to distunguish between
>ports which want to install both foo.sh and foo startup scripts
>(the former to be sourced, the latter to be run in a subshell)?  It
>may be easier just to require port maintainers to rename files/foo.sh.in
>to files/foo.in which they can do at any point the transition period.
>
>
>  
>
>>>My thought is that to oblige port maintainers to make changes in
>>>the short term will be hard.  Give them some time (between points
>>>B. and C. and acceptance of the change will be a lot easier).
>>>
>>>So let's provide intermediate rc, rc.subr and localpkg scripts that
>>>may be larger and more complex, but which don't place an immediate
>>>burden on 13,000 port maintainers.  Then provide a final set of
>>>scripts which do.  The intermediate scripts can provide warning
>>>messages that alert that a change may be needed.
>>>      
>>>
>>I agree.  I'd like to do the spadework to make the major benefits
>>available for 6.0 and then take the time between 6.0 and 7.0 to work
>>towards the flag day.  There's no reason not to make the full transition
>>in ports before 7.0 so all the flagday does is make old junk stop
>>working, as long as we do the work to warn about old style bits from
>>the beginning.
>>
>>    
>>
>I'm surprised you're saying we need to wait as long as 7.0 for the
>flag day.  Isn't that over 18 months away?  Wouldn't something like
>a three or six month transition period be enough?  After a HEADSUP and
>warnings, I'd imagine that would be long enough for port maintainers
>to make the needed changes.
>
>	-jr
>  
>
i think 7.0 is a more reasonable release date to expect the change.  6.0 
is definitely too close for all of the maintainers to make the necessary 
changes.