Re: RFC: Removal of the old rc system from -current

Doug,

I totally understand and support the issues with maintenance.  I do,
however, have a couple of questions:

1.  Have all ports been preened of dependence on rcOG?
2.  What about 3rd party software that is not in ports?

Would it be possible and acceptable to officially deprecate rcOG in 5.1
and then remove it sometime in June or July?  I understand that this
extends the maintenance of rcOG a tiny bit, but it will also help users
and vendors transition.  Also, will any seatbelts be in place to catch
software that tries to do things the rcOG way?

Thanks!

Scott

Doug Barton wrote:
> [ Please respect followups to -arch, and avoid cross-posting responses,
> thanks. ]
> 
> Summary:
> 
> I'm proposing the removal of the old rc system from HEAD, and all
> subsequent 5.x releases.
> 
> Background:
> 
> During the discussion of importing the next generation rc system (rcNG)
> the request was made to follow a "typical" deprecation schedule, with rcNG
> as the default in 5-Release, and the old system (rcOG) still existent but
> deprecated, not to be removed till 6.x. At the time, I agreed to that plan
> as a sort of "wait and see" measure, since it seemed reasonable at the
> time. However, I think it's time to revisit that decision.
> 
> Current situation:
> 
> If you'll pardon a bit of horn blowing, the rcNG team, especially Mike
> Makonnen, has done a great job of bringing over a lot of code from NetBSD,
> making some improvements, and quite a few compatibility patches. The
> existing rcNG system, to the best of our knowledge, is totally
> bug-compatible with rcOG. We've hit all of the project timelines that we
> established for ourselves, and we continue to improve the system, while
> staying responsive to bug reports. That's the good news.
> 
> The bad news is that the status quo leaves us with essentially 3 "rc
> branches" to support. The rcNG code is where most new development is
> occurring. There is also rcOG in HEAD, and the old rc system in RELENG_4.
> This is becoming more and more difficult to support as time goes by. We're
> already seeing features that are added in rcNG that there are no plans to
> migrate to rcOG, mostly because they are 5.x only features. Dropping rcOG
> in HEAD will free up cycles that could then be better spent on developing
> new features, and back-porting useful things to RELENG_4 (whether on OG or
> NG format).
> 
> We're also starting to see some confusion on the part of users about
> having both systems on disk. I haven't seen a _lot_ of posts about this
> yet, but I think that the rate of adoption for -current is still pretty
> slow, so it's hard to judge.
> 
> In fact, I think that since rcNG has been the default for over 7 months
> now, with practically zero reported problems, speaks volumes toward the
> suitability of rcNG as the stand alone code base in 5.x.
> 
> Proposal for the future:
> 
> We'd like to take the following actions:
> 
> 1. Remove the old rc framework prior to the 5.1-Release.
> 
> 2. Backport /etc/rc.subr to RELENG_4 prior to 4.9-Release. The purpose
> here is to allow ports authors to make use of the rcNG system for their
> startup scripts, and to possibly allow us to backport major features that
> just work better in the NG framework.
> 
> 3. Start generating error messages about the compatibility variables we
> are currently supporting. portmap_*, xntpd_*, and single_mountd_enable.
> 
> 
> Your friendly neighborhood rc team is ready and willing to entertain
> discussion on this topic. Particularly, if you're not using rcNG now
> because it lacks some feature that the old system had, we'd really like to
> hear from you.
> 
> Doug
>