1 |
On Tue, Oct 04, 2016 at 08:44:05PM +0000, Duncan wrote: |
2 |
> William Hubbs posted on Mon, 03 Oct 2016 16:59:33 -0500 as excerpted: |
3 |
> |
4 |
> > I want to look into removing grub:0 from the tree; here are my thoughts |
5 |
> > on why it should go. |
6 |
> |
7 |
> I don't disagree with the thought, but have some niggles on the |
8 |
> individual points. Note that I'm not nearly as negative on the idea in |
9 |
> general as the comments on the individual points may suggest on their own. |
10 |
|
11 |
Why bring them up then? ;-) |
12 |
|
13 |
> > - the handbook doesn't document grub:0; we officially only support |
14 |
> > grub:2. |
15 |
> |
16 |
> That's not a reason to remove grub:0 from the tree. If it was, there's |
17 |
> many other alternative boot managers that would need removed as well. |
18 |
> Thankfully, gentoo tends to emphasize choice. =:^) |
19 |
|
20 |
I'm talking about removing the old, obsoleted version of grub, not all |
21 |
of sys-boot/grub. Technically all of grub should have slot 0, but we |
22 |
made grub 2 have slot 2 so people could take longer to migrate. grub 2 |
23 |
has been stable in the tree for over a year. |
24 |
|
25 |
> > - grub:0 can't boot a nomultilib system, so we have to maintain a |
26 |
> > separate package (grub-static) specifically for that setup. |
27 |
> |
28 |
> Grub:0 can _boot_ a no-multilib system just fine. AFAIK the problem is |
29 |
> at build time -- a no-multilib system can't *build* grub:0. |
30 |
> |
31 |
> FWIW I run no-multilib myself, but as I switched from a multilib system |
32 |
> and still had its grub:0 installed and booting when I first went no- |
33 |
> multilib, I know it /boots/ just fine. |
34 |
> |
35 |
> And AFAIK that's actually what grub-static is, a pre-built grub:0 tarball |
36 |
> with an installer that installs the prebuilt pieces in all the right |
37 |
> places, originally developed IIRC by the gentoo/amd64 folks precisely to |
38 |
> solve the amd64 no-multilib build problem. |
39 |
|
40 |
This would actually be another reason to get rid of grub-0, if it can't |
41 |
build on one of our profiles, it will more than likely never be fixed |
42 |
upstream because they are now focused on grub-2.x. |
43 |
|
44 |
> > - Removing grub:0 from the tree doesn't stop you from using it. If |
45 |
> > people really want it I will place it in the graveyard overlay. |
46 |
> |
47 |
> Another alternative would be simply hard-masking it, but leaving it in |
48 |
> place for those who want it. It does still work, and I see no evidence |
49 |
> we're removing it due to security issues or breakage. |
50 |
|
51 |
We are removing it because upstream has a new version of the software |
52 |
and has moved on from this one. For most packages, if foo-1.0 is |
53 |
stable, then foo-2.0 comes to stable, after some point we remove foo-1.0 |
54 |
from the tree. |
55 |
|
56 |
> > - We have custom patches for grub:0, which will never go upstream. |
57 |
> > |
58 |
> > - grub:0 is dead upstream. They have not done any work on it in years. |
59 |
> |
60 |
> Both valid points. |
61 |
> |
62 |
> But I'll make the same point here as I did on a different proposed |
63 |
> package removal thread recently. General gentoo policy is that a dead |
64 |
> upstream (and lack of a gentoo maintainer) isn't sufficient reason to |
65 |
> remove a package if it still works. As long as it's not broken or a |
66 |
> security issue, the general policy is to leave it in the tree for anyone |
67 |
> that needs it. |
68 |
|
69 |
As I said above, I'm not removing sys-boot/grub, just the obsoleted version. |
70 |
|
71 |
> So is grub:0 so broken it justifies removal from the tree, despite |
72 |
> potentially many users still having it installed and working just fine? |
73 |
|
74 |
Think of this as being like module-init-tools vs kmod. Upstream |
75 |
module-init-tools stopped development and told everyone to move to kmod, |
76 |
so we did. This is similar. grub-2.x is now the official version of grub |
77 |
where upstream development happens. grub-0.x is abandoned. |
78 |
|
79 |
> > - The only real problem with grub:2 has to do with pperception. Yes, |
80 |
> > their documentation has a strong preference toward using their |
81 |
> > configuration script (grub-mkconfig) to generate your grub.cfg, but |
82 |
> > this is not required. |
83 |
> |
84 |
> +100. Good gentoo documentation on properly creating and managing your |
85 |
> own grub.cfg without their config script would go a long way here. (This |
86 |
> may already exist, I switched to grub2 while the documentation remained |
87 |
> quite raw.) |
88 |
|
89 |
The problem is that it would be next to impossible to document what a |
90 |
grub.cfg should look like, because that depends so much on how you |
91 |
install your kernels, initramfs, etc. The grub info pages explain all of |
92 |
what can go in grub.cfg. |
93 |
|
94 |
> > So, I want to make a plan to lastrite grub:0 and grub-static. |
95 |
> > |
96 |
> > I'm thinking, in about a week, p.mask grub:0 along with grub-static and |
97 |
> > send out a lastrites msg with a 30 day removal notice. |
98 |
> |
99 |
> I'd suggest that this is a sufficiently huge change (comparable in level |
100 |
> to the openrc upgrade you handled a few years back, tho obviously not as |
101 |
> wide ranging in terms of other packages affected) for anyone still on |
102 |
> grub:0 that a far longer warning and removal period is justified. |
103 |
> |
104 |
> I'd suggest something more like six months, with a news item beginning |
105 |
> the period, and the traditional 30-day package-masking five months later, |
106 |
> to encourage the laggerts. |
107 |
|
108 |
I don't agree with a news item then no action after that for 5 months |
109 |
because people will read the newsitem and not take any action, then they |
110 |
will forget and we'll be back to having this discussion when the |
111 |
traditional lastrites happens. |
112 |
|
113 |
I also don't agree with a really long time like this for the removal for |
114 |
the same reason; people will forget then wonder what happened when |
115 |
things are removed. |
116 |
|
117 |
Another thing to consider is, upgrading the grub package doesn't change how your |
118 |
system boots. That change doesn't happen until you run grub-install from |
119 |
the newer version of grub. |
120 |
|
121 |
> And again, is grub:0 really more broken than say lilo? I believe it |
122 |
> remains more flexible, even if not as flexible as grub:2. If it's not |
123 |
> more broken, what justifies removal from the tree when lilo and various |
124 |
> other similar boot manager packages remain? |
125 |
|
126 |
Again, I'm not removing sys-boot/grub, so comparing this to removing |
127 |
sys-boot/syslinux, sys-boot/lilo etc does not feel right to me. |
128 |
|
129 |
William |