1 |
Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted: |
2 |
|
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. |
14 |
|
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. |
22 |
|
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. |
27 |
|
28 |
I think it's worth noting two small details of williamh's original mail |
29 |
that may have gone unnoticed: |
30 |
|
31 |
1) He proposes seding the *LIVE* ebuild, which I take as meaning |
32 |
openrc-9999. |
33 |
|
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. |
37 |
|
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? |
43 |
|
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. |
54 |
|
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. |
60 |
|
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. |
66 |
|
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. |
71 |
|
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. |
75 |
|
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... |
84 |
|
85 |
I was brown-bagging /that/ one for a few days! =:^\ |
86 |
|
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! |
89 |
|
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 |