1 |
On Wed, Dec 11, 2013 at 09:28:09PM +0000, Duncan wrote: |
2 |
> Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted: |
3 |
> |
4 |
> > On 12/11/2013 08:47 PM, Chris Reffett wrote: |
5 |
> >> On 12/11/2013 3:41 PM, William Hubbs wrote: |
6 |
> >>> |
7 |
> >>> My thought is to rename our "rc" to "openrc", since that would be |
8 |
> >>> unique. |
9 |
> >>> |
10 |
> >>> I know at least one thing that will break is everyone's inittab, so |
11 |
> >>> should I sed their inittab in our live ebuild or expect them to fix it |
12 |
> >>> and give a warning? I know that once OpenRC with this change is |
13 |
> >>> released, it will need to probably be p.masked until there is a new |
14 |
> >>> release of sysvinit that updates the inittab. |
15 |
> |
16 |
> >> The idea of running a sed on inittab in an ebuild, no matter what the |
17 |
> >> context, terrifies me. Perhaps we can ease this in slowly by renaming |
18 |
> >> rc -> openrc and symlinking rc -> openrc and making a release with that |
19 |
> >> change concurrent with a news item? Or even just do that in the ebuild |
20 |
> >> rather than in the actual sources. I don't think Debian will keel over |
21 |
> >> and die if it takes a little extra time for the change to go through, |
22 |
> >> and it beats a ton of broken systems. |
23 |
> |
24 |
> > +1 |
25 |
> > |
26 |
> > The ebuild can grep the inittab and it if finds an "rc" there, just |
27 |
> > print a huge warning telling the user to migrate || die. |
28 |
> |
29 |
> I think it's worth noting two small details of williamh's original mail |
30 |
> that may have gone unnoticed: |
31 |
> |
32 |
> 1) He proposes seding the *LIVE* ebuild, which I take as meaning |
33 |
> openrc-9999. |
34 |
> |
35 |
> 2) He then proposes p.masking an openrc release until a sysvinit release |
36 |
> updating inittab, with the contrast between that and the LIVE ebuild |
37 |
> proposal thus again emphasized. |
38 |
> |
39 |
> Question: How many people run the openrc-9999 LIVE ebuild, and given that |
40 |
> it's masked and general gentoo policy is that people running live ebuilds |
41 |
> should expect to keep the pieces of they can't handle occasionally |
42 |
> unpredicted changes, how much should we actually worry about doing just |
43 |
> that? |
44 |
|
45 |
We don't have to worry about the live ebuild per se, I was more |
46 |
concerned about what to do when the next release comes out. |
47 |
|
48 |
Duncan, it sounds like you would know how to recover with the live |
49 |
ebuild. |
50 |
|
51 |
But, with the proposal of creating a symlink from /sbin/rc->openrc, |
52 |
there would no longer be a reason to p.mask the next release, because |
53 |
people would be able to upgrade. A news item would definitely be |
54 |
appropriate though. |
55 |
|
56 |
William |