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
