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

[Brooks Davis]

On Wed, Jun 15, 2005 at 12:29:48PM -0400, 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.

The reason I think we may need an early script is that we're going to be
moving some scripts well before localpkg.

> > 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 think *.* is fine.  I'd prefer to complain about them from the
beginning so we catch any exceptions (possibly suppressing warnings for
obvious examples like *.bak, *.orig, *.sample).

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

I agree.

> Are we in agreement that the intermediate "B." versions should not
> break anything and should not require any changes by port maintainers?

I think this is a good idea and maximizes our changes of successful
integration.

> > 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)

I'd rather not support sourcing at all until full transition.  I'd
rather force porters to install files in /etc/rc.d for now if they want
sourcing.

> 		- quietly run (in subshell) all other files with
> 		  rcorder tags
> 
> 		- warn and don't run any remaining files
> 
> 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.

I'm not suggesting keywords, I'm suggesting checking for:

^# (REQUIRE|PROVIDE|BEFORE|KEYWORD):

This seems like a reasonable thing to do because none of these scripts
will run now.

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

Ah, I see why the disconnect on localpkg-early above.  I was thinking
we'd do the rcordering in /etc/rc in B which would change things a bit,
but could still be basically compatible.  Just doing it in localpkg
seems like it may not offer the benefits people want.

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

I'm more concerned about supporting installing .sh scripts on 5.x for
the next two years than I am about supporting the installation of .sh
scripts to be sourced two years now.

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

If we can't make major changes to the startup script processing in the
6.x line once 6.0-RELEASE happens.  Anything that would break user
scripts would be specifically disallowed.  The rule of the project is
that we generally have to deprecate a major interface for one release
branch before we can break it.  The rules for determining which scripts
are run definitely falls into this category.  Remember, we're not just
dealing with ports, we're also dealing with weird user scripts so we
need to give them plenty of warning.  If we weren't so close to 6.0
release, we might be able to get away with warnings in 5.x and full
deprecation in 6.0, but I think we're too late for that.  This is why
I'd like to see some modifications to /etc/rc in addition to localpkg.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20050615/fe76a571/attachment.bin