Re: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

On Wed, Dec 11, 2013 at 09:28:09PM +0000, Duncan wrote:
> Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted:
> 
> > On 12/11/2013 08:47 PM, Chris Reffett wrote:
> >> On 12/11/2013 3:41 PM, William Hubbs wrote:
> >>>
> >>> My thought is to rename our "rc" to "openrc", since that would be
> >>> unique.
> >>>
> >>> I know at least one thing that will break is everyone's inittab, so
> >>> should I sed their inittab in our live ebuild or expect them to fix it
> >>> and give a warning? I know that once OpenRC with this change is
> >>> released, it will need to probably be p.masked until there is a new
> >>> release of sysvinit that updates the inittab.
> 
> >> The idea of running a sed on inittab in an ebuild, no matter what the
> >> context, terrifies me. Perhaps we can ease this in slowly by renaming
> >> rc -> openrc and symlinking rc -> openrc and making a release with that
> >> change concurrent with a news item? Or even just do that in the ebuild
> >> rather than in the actual sources. I don't think Debian will keel over
> >> and die if it takes a little extra time for the change to go through,
> >> and it beats a ton of broken systems.
> 
> > +1
> > 
> > The ebuild can grep the inittab and it if finds an "rc" there, just
> > print a huge warning telling the user to migrate || die.
> 
> I think it's worth noting two small details of williamh's original mail 
> that may have gone unnoticed:
> 
> 1) He proposes seding the *LIVE* ebuild, which I take as meaning 
> openrc-9999.
> 
> 2) He then proposes p.masking an openrc release until a sysvinit release 
> updating inittab, with the contrast between that and the LIVE ebuild 
> proposal thus again emphasized.
> 
> Question: How many people run the openrc-9999 LIVE ebuild, and given that 
> it's masked and general gentoo policy is that people running live ebuilds 
> should expect to keep the pieces of they can't handle occasionally 
> unpredicted changes, how much should we actually worry about doing just 
> that?

We don't have to worry about the live ebuild per se, I was more
concerned about what to do when the next release comes out.

Duncan, it sounds like you would know how to recover with the live
ebuild.

But, with the proposal of creating a symlink from /sbin/rc->openrc,
there would no longer be a reason to p.mask the next release, because
people would be able to upgrade. A news item would definitely be
appropriate though.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]