Date: Sat, 26 Apr 2003 23:58:04 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current Message-ID: <20030426231507.K657@znfgre.qbhto.arg> In-Reply-To: <3EAB7486.2060107@btc.adaptec.com> References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com><3EAB7486.2060107@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Apr 2003, Scott Long wrote:
> There's a big difference between, "dougb and friends no longer support
> nor commit to rcOG, it's going away so don't use it"
We've been saying this, although perhaps not as stridently as we could
have, since we made NG the default 7 months ago. If they haven't caught
the clue by now, I don't see how giving them more notice is going to help.
> Invariably there are going to be people/vendors out there that are
> abusing rcOG, have been lazy for the last 7 months and haven't adapted
> their systems to rcNG, and will be highly cranky over rcOG disappearing.
> Having a formal deprecation period gives these people some warning and
> diminishes their ability to whine. =-)
Once again, I have to ask you for a concrete example. If any 3rd party has
scripts that run out of /usr/local/etc/rc.d, then they will continue to
work just like they always have. If they have been abusing rcOG by
actually editing the scripts that exist in /etc, their stuff is badly
broken already, and the presence or absence of rcOG in the base isn't
going to matter, since they are already depending on customized versions.
If we were talking about a kernel API, I think that your request would be
justified. But we're not. We're talking about an "interface" that has
always provided well defined 3rd party support that will not be removed or
changed, merely enhanced.
The other thing to keep in mind is that unlike a kernel, or other
interface, we have no power to actually take functioning rcOG scripts away
from users. Even mergemaster doesn't delete files. People with wacky,
broken stuff can keep running it that way forever for all I care. Also the
stuff will still be there in CVS, just as unsupported and un-committed-to
as it would be if we didn't cvs rm it.
What I'm talking about is removing it from the default installation to
avoid confusing new users, and to further reinforce the fact that it's
gone away to anyone who still hasn't caught the clue. This will not cause
any problems to those with existing rcOG installations that they depend
on, or people who've converted to rcNG.
> Adding a big "if [ "${rc_ng}" = "NO" ]; then echo "rc_ng=NO is
> deprecated, unsupported, and will go away in the next release"; fi" to
> the scripts allows us to cover our rears, makes everyone happy, and lets
> you all off the hook for providing rcOG support.
That's a good idea, I'm testing something like that right now, thanks.
However, it will only be useful for people who upgrade /etc/rc*, which
doesn't include the people you're most concerned about.
Before you have another knee-jerk REaction to my proposal, please stop and
think about how much different this scenario is than something like a
kernel interface or binary. Then please try to come up with a concrete
example of how things will break if the code is cvs rm'ed. I'm betting
that you can't. :)
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030426231507.K657>