Adding /usr/local/etc/rc.d to the base rcorder

[Brooks Davis]

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.

> > - 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.

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.  My concern is that we may end up having
to require a "portupgrade -af" and that's going to be unacceptable on
6-STABLE.

> 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.

I agree that it's worth not doing the MFC just to push people toward
RELENG_6.  

> > - 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.

That sounds reasonable.  My thought would be to MFC to 6 and then start
griping about old style scripts in HEAD pretty much immediately.

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.

-- Brooks

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20051202/3d2e94c8/attachment.bin