Date: Tue, 14 Jun 2005 09:47:32 -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: <20050614134732.GB16676@linwhf.opal.com> In-Reply-To: <20050613155211.GB19722@odin.ac.hmc.edu> References: <20050609003459.GK37208@linwhf.opal.com> <20050609050517.GA28710@odin.ac.hmc.edu> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It seems to me that TWO changes will be needed to make this transition. The transition modifies the semantics of how files in the local rc.d dirs are handled. Right now, local "foo.sh" files are executed in a subshell. After we're done, we want "foo" to be executed in a subshell and "foo.sh" to be sourced. There are possible negative consequences of sourcing all "foo.sh" files, so two changes will probably be needed, one now in the short term which adds the rcordering capability and preserves other semantics, and one later on which brings all semantics into line. Something like this: 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 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 - rename "[0-9]foo.sh" scripts to something more suitable - move "foo.xyz" (e.g., ".sample") files elsewhere 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. -jr On Jun 13, 08:52, Brooks Davis wrote: > On Sun, Jun 12, 2005 at 10:29:45PM -0700, Doug Barton wrote: > > Brooks Davis wrote: > >=20 > > >I don't like the idea of tagging all the scripts. First, it makes the > > >update suck. > >=20 > > rm /etc/rc.d/* ; mergemaster -i > >=20 > > I understand that this mechanism is a little more invasive, but it uses= the=20 > > existing rc.d framework without adding too much additional code. Also,= =20 > > using keywords makes this really easy to work around, since keywords ar= e=20 > > harmless if they aren't actually invoked. >=20 > I know about this workaround. It's fine unless you've modified even a > single script. >=20 > > >Second, that's a lot > > >places to keep state up to date. JR's proposal of using a marker scri= pt > > >had the downside of adding slightly more code to /etc/rc, but the > > >advantage of not having to keep all the files in the right place. > >=20 > > I'm not sure what you mean by "a lot of places to keep state." This is = a=20 > > one-time modification, and any scripts that we need to add to bootearly= are=20 > > easily added. The disadvantage to a marker script is that if some other= =20 > > dependency gets juggled in another script, the marker could run in a=20 > > different order. By using keywords we can be 100% sure what will happen= in=20 > > each phase. >=20 > What I like about the marker script is that dependency changes still > work. I don't want to have to figure out every script that needs to > change if I add "# BEFORE: mountcritremote" to a script or if I change a > script that previously ran before mountcritremote to run after it. This > is the strength of rc.d. Down the path of adding tags to indiacte > startup order lies SysV init. That's not all bad, but I'd like to think > we chose rc.d over SysV init because it was better not because it was > less SysV. >=20 > > >The local_startup collector looks pretty good.=20 > >=20 > > Thanks. > >=20 > > > I'm not 100% how I feel > > >about the *.sample exception. On one hand it seems like the safest > > >thing to do, on the other hand, it's the sort of feature that tends to > > >hang on forever.=20 > >=20 > > I would say that's accurate. :) I think that when we get farther down t= he=20 > > road of the conversion (and we can be sure that things won't start=20 > > accidentally if the user doesn't put the right things in=20 > > /etc/rc.conf[.local]) then we can carp on this more. > >=20 > > >I'd be slightly inclined to complain about .sample > > >scripts that are executable to try and get people to stop installing > > >them. We should almost certainly complain about script that aren't *.= sh > > >that are not executable. Effectivly those will all be all port bugs. > >=20 > > I agree, but my preference would be that we also hold off on this till= =20 > > we're further down the road of the transition. I'm flexible on all this= =20 > > stuff though, let me know what you think. >=20 > I generally prefer to complain early. The sooner we ship a release that > gripes, the sooner the users start beating up on port maintiners to make > the warning go away. :-) We can't generally drop support for "features" > until we've warned for a good part of a branch. I'd like see warnings > about older scripts by the time 6.x goes production ready. >=20 > -- Brooks >=20 > --=20 > 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 --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQDVAwUBQq7f80kkqUax7f6FAQLn7gX/Zs7O1dhC1LKzefN+aUVXk2X/tTt/3ptJ TfNYDv2CF/g8l0uBUZgybzjUL0lvQXO4ivm+oWNd+90MSB0zz10Exz7+SoZL323b 2lUu8QIa99uwf5dezZDAycUjKEJDTB8UZ2ttwgOOtOq3xRlmeD4Zzy834yf0jR+a q0dsIfuxc3MgXaTmsflMTQ3GuiXXLg/y7hhxCgheopVj20GeM1YAAEQUDsMISz+Y 9yMM9z1iqrCyTNIRRdveXPS25mbuWuPZ =nRXM -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050614134732.GB16676>