Date: Wed, 30 Nov 2005 17:20:11 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-rc@freebsd.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder Message-ID: <438E4FCB.8060806@FreeBSD.org> In-Reply-To: <20051201003525.GB21393@odin.ac.hmc.edu> References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: > >>My patch to implement all this is at >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. > > > This looks pretty good to me. Thanks for working on this. No problem. I had a feeling you'd like the fact that I dropped all that keyword stuff. :) > A few comments: > > - I have this vague feeling that we should replace most dependencies on > mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. > This isn't important. :) Right, this can be revisited later if needed. The more I thought about this the more I liked the concept of what JR suggested, although obviously I implemented it in a slightly different manner. I'm hesitant to add more pseudo-targets, as I think using mountcritremote is a good "clear bright line" for this purpose. I also have a fantasy down the road (not sure how to implement it yet) of making the point to split early/late configurable. For example, I can imagine a scenario where someone might want to put the split at mountcritlocal. However, this is a good safe place to start. > - Is the exclusion of *.sample sufficient? We obviously don't want to > be too broad, but I'd be inclined to include .bak, .orig, and maybe > .sav for now. Heh, that's the opposite of what you said last time. :) I actually decided to take your advice and take all the pain up front. I think if we start with this in HEAD, and give people sufficient warning, we can handle the problem cases pretty easily. And of course, if I'm wrong, this is also easily fixed. > - I'm worried about including .sh scripts in the new list during the > transition period. It seems likely that is going to cause significant > pain. Once again, I hope not, but this is the area where I have the most concern. My post was pretty long already, so I cut the section where I discussed the relative virtues of foo vs. foo.sh, but one thing I do plan to offer port authors is help with installing their scripts as foo instead of foo.sh if OSVERSION is > N, where we can slide N down through 610000 at least. At some point (years down the road obviously) when we've dropped support for RELENG_5 in ports, this can all be removed. I'm still ambivalent about whether to backport this into RELENG_5 btw. On the one hand it wouldn't be too hard to do, but on the other hand I'd like to do everything I can to convince people of the value of moving to RELENG_6 asap. Thoughts on this topic are welcome. > - When do we want to start complaining about old scripts? One idea is > to first ban them in ports and have Kris add a check for them on the > ports cluster followed by enabling a warning in the startup scripts. My feeling is that we probably want to deprecate them in 7-Stable, and stop supporting them in 8-Stable, but I'm open to suggestions here too. Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438E4FCB.8060806>