[gentoo-dev] Re: rfc: the demise of grub:0

[Duncan]

William Hubbs posted on Mon, 03 Oct 2016 16:59:33 -0500 as excerpted:

> I want to look into removing grub:0 from the tree; here are my thoughts
> on why it should go.

I don't disagree with the thought, but have some niggles on the 
individual points.  Note that I'm not nearly as negative on the idea in 
general as the comments on the individual points may suggest on their own.

> - the handbook doesn't document grub:0; we officially only support
>   grub:2.

That's not a reason to remove grub:0 from the tree.  If it was, there's 
many other alternative boot managers that would need removed as well.  
Thankfully, gentoo tends to emphasize choice. =:^)

> - There are multiple bugs open against grub:0 (15 at my last count). A
>   number of these as I understand it are because of custom patches we
>   apply.

+1

> - grub:0 can't boot a nomultilib system, so we have to maintain a
>   separate package (grub-static) specifically for that setup.

Grub:0 can _boot_ a no-multilib system just fine.  AFAIK the problem is 
at build time -- a no-multilib system can't *build* grub:0.

FWIW I run no-multilib myself, but as I switched from a multilib system 
and still had its grub:0 installed and booting when I first went no-
multilib, I know it /boots/ just fine.

And AFAIK that's actually what grub-static is, a pre-built grub:0 tarball 
with an installer that installs the prebuilt pieces in all the right 
places, originally developed IIRC by the gentoo/amd64 folks precisely to 
solve the amd64 no-multilib build problem.

> - Removing grub:0 from the tree doesn't stop you from using  it. If
>   people really want it I will place it in the graveyard overlay.

Another alternative would be simply hard-masking it, but leaving it in 
place for those who want it.  It does still work, and I see no evidence 
we're removing it due to security issues or breakage.

> - We have custom patches for grub:0, which will never go upstream.
>
> - grub:0 is dead upstream. They have not done any work on it in years.

Both valid points.

But I'll make the same point here as I did on a different proposed 
package removal thread recently.  General gentoo policy is that a dead 
upstream (and lack of a gentoo maintainer) isn't sufficient reason to 
remove a package if it still works.  As long as it's not broken or a 
security issue, the general policy is to leave it in the tree for anyone 
that needs it.

So is grub:0 so broken it justifies removal from the tree, despite 
potentially many users still having it installed and working just fine?

> - The only real problem with grub:2 has to do with pperception. Yes,
>   their documentation has a strong preference toward using their
>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>   this is not required.

+100.  Good gentoo documentation on properly creating and managing your 
own grub.cfg without their config script would go a long way here.  (This 
may already exist, I switched to grub2 while the documentation remained 
quite raw.)

An alternative would be a pointer to quality Arch documentation, or the 
like.  Obviously we're unlikely to ever get it from upstream, tho they do 
provide generally reasonable manpage style (tho not specifically manpage) 
documentation, just not anything really user level.

> So, I want to make a plan to lastrite grub:0 and grub-static.
>
> I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
> send out a lastrites msg with a 30 day removal notice.

I'd suggest that this is a sufficiently huge change (comparable in level 
to the openrc upgrade you handled a few years back, tho obviously not as 
wide ranging in terms of other packages affected) for anyone still on 
grub:0 that a far longer warning and removal period is justified.

I'd suggest something more like six months, with a news item beginning 
the period, and the traditional 30-day package-masking five months later, 
to encourage the laggerts.


And again, is grub:0 really more broken than say lilo?  I believe it 
remains more flexible, even if not as flexible as grub:2.  If it's not 
more broken, what justifies removal from the tree when lilo and various 
other similar boot manager packages remain?

That said, as I said at the beginning, I'm not entirely opposed, either.  
Primarily, I simply don't see the sense in removing grub:0 and grub-
static if lilo and etc remain, and it seems to me that if we're actually 
going to be removing grub:0 and grub-static, we should be considering 
removal of the others as well, because in practice, grub:0 isn't really 
more limiting or more broken than they are.  And removal of all those 
/would/ be a shame, as well as arguably an abrogation of the emphasis on 
choice that gentoo is known for.

-- 
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