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

[Duncan <1i5t5.duncan@cox.net>]

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?

*I ask the above as an openrc-9999 user myself!  Of course, I also not 
only follow this list for heads-up notes such as this, but I also have a 
partially scripted update routine that checks openrc for changes every 
time I update, runs git log to check them out if there are any, and 
further runs git show on anything that I have questions about, *BEFORE* I 
actually do the update.  There's certainly a small window between my 
checks and the actual run of the openrc emerge, during which a git commit 
or two might in theory slip in, but other than that, I'd see such a 
change BEFORE I ever actually installed that openrc live update in the 
first place.

As a result, while I probably wouldn't have noted the linkage to inittab 
without this mail, I would have at least been aware of the name change 
when I did that live-build update, and would be prepared to boot with 
init=/bin/bash and find the problem, should it come to that, as I know it 
well might given the live-ebuild I choose to run.

Meanwhile, given the openrc-9999 bug history, with me as about the only 
bug reporter, I don't think there's that many actually running it.  
Certainly nothing I'd qualify as "a ton of broken systems" even if 
there's no sed and every one of those running it fails to see the warning 
until they've rebooted and suffered the consequences.

And the p.mask proposal for an actual release with the change, until a 
parallel sysvinit package update likely unmasked at the same time, does 
sound appropriately more responsible for ~arch as well, thus making both 
proposals at least not entirely insane.

Tho I too am a bit uncomfortable about sedding inittab directly from the 
ebuild.  Assuming it can work, the more gradual symlink and safer grep 
proposals sound much more reasonable, even at the live ebuild level.

Tho that said, given that I /am/ running a live ebuild for something as 
critical as openrc, if sed screws up and replaces the current inittab 
with an empty file, I'd better be prepared to deal with it.  That's part 
of the risk I took when unmasking that ebuild.  Now I'd be rather more 
annoyed if the ebuild pulled a trick like I did in one of my own scripts 
a few years ago, such that I used the wrong variable name as the absolute 
prefix to a rm command run as root, and said mis-named variable ended up 
null...

I was brown-bagging /that/ one for a few days! =:^\

But killing a single inittab file, meh!  If I can't deal with that, I've 
no business running an openrc-9999 version!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman