Date: Mon, 13 Jun 2005 08:52:11 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-rc@FreeBSD.org, "J.R. Oldroyd" <fbsd@opal.com> Subject: Re: Use of rcorder for local rc.d/*.sh scripts Message-ID: <20050613155211.GB19722@odin.ac.hmc.edu> In-Reply-To: <42AD19C9.2040403@FreeBSD.org> References: <20050608233802.GA29707@odin.ac.hmc.edu> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 t= he=20 > existing rc.d framework without adding too much additional code. Also,=20 > using keywords makes this really easy to work around, since keywords are= =20 > harmless if they aren't actually invoked. I know about this workaround. It's fine unless you've modified even a single script. > >Second, that's a lot > >places to keep state up to date. JR's proposal of using a marker script > >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 a= re=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 i= n=20 > each phase. 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. > >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 the= =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. 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. -- Brooks --=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 --jho1yZJdad60DJr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCrauqXY6L6fI4GtQRAoK0AJ4yT9ReWnBsuKnbuR9tiDI6lzyMwQCfcteI cpOB8bx6UDUIoiuSQTVWaAo= =xM69 -----END PGP SIGNATURE----- --jho1yZJdad60DJr+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050613155211.GB19722>