Date: Wed, 15 Jun 2005 12:29:48 -0400 From: "J.R. Oldroyd" <fbsd@opal.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Doug Barton <dougb@FreeBSD.org>, freebsd-rc@FreeBSD.org Subject: Re: Use of rcorder for local rc.d/*.sh scripts Message-ID: <20050615162948.GG16676@linwhf.opal.com> In-Reply-To: <20050614172740.GC20371@odin.ac.hmc.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jun 14, 10:27, Brooks Davis wrote: > On Tue, Jun 14, 2005 at 09:47:32AM -0400, J.R. Oldroyd wrote: >=20 > > 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 > >=20 > > 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 >=20 > 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. >=20 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. >=20 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. >=20 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 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. >=20 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 >=20 > I think we should be able to automate this via USE_RC_SUBR and/or > RC_ORDER. >=20 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). > >=20 > > 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. >=20 > 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. >=20 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 --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQDVAwUBQrBXfEkkqUax7f6FAQJ+wgX/e1WdfoHb1qXxTAGRENmxITXsZT9xSTvj 12+bejjPwdic9NDXpgScSmrC+O/OCsI93O/ghHRl9d0koTcG9cGKRFkDEBefE3ZO ZOF1WlqhcIqhzKq2ejDA/jVH/D0qX0wwDkmhD6Vw0ZUW95p0m3fzSB5GRx/exBY+ m1hJWc/A6alXe1GzoWyWDNb1pZN96hsqRN4yuOi3jOLnvCenZrwL2BYhxlk8fJB2 MjISlpppMqy4WcnqjmdjqmEVWbQyyRot =+2Sy -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050615162948.GG16676>