Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC
Date: Wed, 11 Dec 2013 21:29:17
Message-Id: pan$d940e$5a1ff5d7$6bba616c$
In Reply to: Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC by Markos Chandras
1 Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted:
3 > On 12/11/2013 08:47 PM, Chris Reffett wrote:
4 >> On 12/11/2013 3:41 PM, William Hubbs wrote:
5 >>>
6 >>> My thought is to rename our "rc" to "openrc", since that would be
7 >>> unique.
8 >>>
9 >>> I know at least one thing that will break is everyone's inittab, so
10 >>> should I sed their inittab in our live ebuild or expect them to fix it
11 >>> and give a warning? I know that once OpenRC with this change is
12 >>> released, it will need to probably be p.masked until there is a new
13 >>> release of sysvinit that updates the inittab.
15 >> The idea of running a sed on inittab in an ebuild, no matter what the
16 >> context, terrifies me. Perhaps we can ease this in slowly by renaming
17 >> rc -> openrc and symlinking rc -> openrc and making a release with that
18 >> change concurrent with a news item? Or even just do that in the ebuild
19 >> rather than in the actual sources. I don't think Debian will keel over
20 >> and die if it takes a little extra time for the change to go through,
21 >> and it beats a ton of broken systems.
23 > +1
24 >
25 > The ebuild can grep the inittab and it if finds an "rc" there, just
26 > print a huge warning telling the user to migrate || die.
28 I think it's worth noting two small details of williamh's original mail
29 that may have gone unnoticed:
31 1) He proposes seding the *LIVE* ebuild, which I take as meaning
32 openrc-9999.
34 2) He then proposes p.masking an openrc release until a sysvinit release
35 updating inittab, with the contrast between that and the LIVE ebuild
36 proposal thus again emphasized.
38 Question: How many people run the openrc-9999 LIVE ebuild, and given that
39 it's masked and general gentoo policy is that people running live ebuilds
40 should expect to keep the pieces of they can't handle occasionally
41 unpredicted changes, how much should we actually worry about doing just
42 that?
44 *I ask the above as an openrc-9999 user myself! Of course, I also not
45 only follow this list for heads-up notes such as this, but I also have a
46 partially scripted update routine that checks openrc for changes every
47 time I update, runs git log to check them out if there are any, and
48 further runs git show on anything that I have questions about, *BEFORE* I
49 actually do the update. There's certainly a small window between my
50 checks and the actual run of the openrc emerge, during which a git commit
51 or two might in theory slip in, but other than that, I'd see such a
52 change BEFORE I ever actually installed that openrc live update in the
53 first place.
55 As a result, while I probably wouldn't have noted the linkage to inittab
56 without this mail, I would have at least been aware of the name change
57 when I did that live-build update, and would be prepared to boot with
58 init=/bin/bash and find the problem, should it come to that, as I know it
59 well might given the live-ebuild I choose to run.
61 Meanwhile, given the openrc-9999 bug history, with me as about the only
62 bug reporter, I don't think there's that many actually running it.
63 Certainly nothing I'd qualify as "a ton of broken systems" even if
64 there's no sed and every one of those running it fails to see the warning
65 until they've rebooted and suffered the consequences.
67 And the p.mask proposal for an actual release with the change, until a
68 parallel sysvinit package update likely unmasked at the same time, does
69 sound appropriately more responsible for ~arch as well, thus making both
70 proposals at least not entirely insane.
72 Tho I too am a bit uncomfortable about sedding inittab directly from the
73 ebuild. Assuming it can work, the more gradual symlink and safer grep
74 proposals sound much more reasonable, even at the live ebuild level.
76 Tho that said, given that I /am/ running a live ebuild for something as
77 critical as openrc, if sed screws up and replaces the current inittab
78 with an empty file, I'd better be prepared to deal with it. That's part
79 of the risk I took when unmasking that ebuild. Now I'd be rather more
80 annoyed if the ebuild pulled a trick like I did in one of my own scripts
81 a few years ago, such that I used the wrong variable name as the absolute
82 prefix to a rm command run as root, and said mis-named variable ended up
83 null...
85 I was brown-bagging /that/ one for a few days! =:^\
87 But killing a single inittab file, meh! If I can't deal with that, I've
88 no business running an openrc-9999 version!
90 --
91 Duncan - List replies preferred. No HTML msgs.
92 "Every nonfree program has a lord, a master --
93 and if you use the program, he is your master." Richard Stallman


Subject Author
Re: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC William Hubbs <williamh@g.o>