Date: Fri, 02 Dec 2005 17:23:49 -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: <4390F3A5.2000300@FreeBSD.org> In-Reply-To: <20051202172206.GC22464@odin.ac.hmc.edu> References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> <438E4FCB.8060806@FreeBSD.org> <20051202172206.GC22464@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: > On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote: >> 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. > > Ah, that makes sense. I do have to say that the names for the mount > bit are misleading. mountcritlocal mounts everything local, not just > important things and mountcritremote does the same. I like the idea of > being able to start at mountcritlocal. That will actually be possible > on almost all systems including all the diskless systems I build. I considered making mountcritlocal the starting point initially, however when looking at what gets started between it and mountcritremote, I decided that there weren't going to be a whole lot of ports that would want to insert themselves in between. As with all things, this can be revisited down the road if necessary. >>> - 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 should also point out the rc.subr also excludes '*[~#]|*.OLD|*.orig|*,v', so I figured anything that was left was worth carping about. >>> - 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. > > My concern isn't switching port over, that's a fairly easy task. > Instead, it's dealing with the transition period where every halfbaked > already installed script in /usr/local/etc/rc.d has the opportunity to > royally screw up the entire boot process by stomping on global variable > since it's run as a .sh script. Yep, that's a big concern, but it's pain that is inevitable if we're ever going to make this transition. > My concern is that we may end up having > to require a "portupgrade -af" and that's going to be unacceptable on > 6-STABLE. Well, keep in mind that there are only about 650 ports that install startup scripts (by my count). If we get the ones that need fixing done, and versions rolled forward sooner rather than later, the RELENG_6 folks shouldn't feel too much of the pain, it will mostly have been worked out in HEAD. > The real issue in my mind is actually not so much the transition in the > base system as the transition in ports. That's really a policy question > for portmgr. I'd personally like to see an immediate ban on non rc.subr > scripts enforced by a test on the ports cluster and a round of marking > problem ports BROKEN. That would probably fix things in a matter of > weeks. After all, rc.subr scripts are easy to write and if there's a > hugely complicated script that the maintainer doesn't want to convert, > they can always install in over in libexec and wrap it with a simple > rc.subr script. Feel free to bring that suggestion up on the -ports list. :) I am hesitant to go that route simply because I don't like telling other developers, "Here is a whole big bunch o' work for you, have a nice day." I'm actually interested to see what will happen with the existing scripts that are named *.sh. I have 8 *.sh scripts in /usr/local/etc.rc.d, and only 1 failed. Assuming that this 12.5% failure rate is representative (and there is no evidence that it is), that's only 81.25 ports that need fixing, which leads me to believe that the transition can be gradual rather than abrupt, but at this point I think we'll just have to wait and see. Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4390F3A5.2000300>