Date: Wed, 15 Jun 2005 12:51:08 -0400 From: JM <jmartin37@speakeasy.net> To: "J.R. Oldroyd" <fbsd@opal.com> Cc: Doug Barton <dougb@FreeBSD.org>, freebsd-rc@FreeBSD.org Subject: Re: Use of rcorder for local rc.d/*.sh scripts Message-ID: <42B05C7C.6060301@speakeasy.net> In-Reply-To: <20050615162948.GG16676@linwhf.opal.com> References: <42A89CD7.1080404@FreeBSD.org> <20050609201017.GA10248@odin.ac.hmc.edu> <42A8A91B.8000402@FreeBSD.org> <20050609210223.GB16168@odin.ac.hmc.edu> <20050612121504.K844@ync.qbhto.arg> <20050613005533.GA28966@odin.ac.hmc.edu> <42AD19C9.2040403@FreeBSD.org> <20050613155211.GB19722@odin.ac.hmc.edu> <20050614134732.GB16676@linwhf.opal.com> <20050614172740.GC20371@odin.ac.hmc.edu> <20050615162948.GG16676@linwhf.opal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42B05C7C.6060301>