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

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6150 bytes --]

On Tue, Oct 04, 2016 at 08:44:05PM +0000, Duncan wrote:
> 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.
 
 Why bring them up then?  ;-)

> > - 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. =:^)
 
 I'm talking about removing the old, obsoleted version of grub, not all
 of sys-boot/grub. Technically all of grub should have slot 0, but we
 made grub 2 have slot 2 so people could take longer to migrate. grub 2
 has been stable in the tree for over a year.

> > - 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.
 
 This would actually be another reason to get rid of grub-0, if it can't
 build on one of our profiles, it will more than likely never be fixed
 upstream because they are now focused on grub-2.x.

> > - 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 are removing it because upstream has a new version of the software
and has moved on from this one. For most packages, if foo-1.0 is
stable, then foo-2.0 comes to stable, after some point we remove foo-1.0
from the tree.

> > - 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.
 
 As I said above, I'm not removing sys-boot/grub, just the obsoleted version.

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

Think of this as being like module-init-tools vs kmod. Upstream
module-init-tools stopped development and told everyone to move to kmod,
so we did. This is similar. grub-2.x is now the official version of grub
where upstream development happens. grub-0.x is abandoned.

> > - 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.)
 
The problem is that it would be next to impossible to document what a
grub.cfg should look like, because that depends so much on how you
install your kernels, initramfs, etc. The grub info pages explain all of
what can go in grub.cfg.

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

I don't agree with a news item then no action after that for 5 months
because people will read the newsitem and not take any action, then they
will forget and we'll be back to having this discussion when the
traditional lastrites happens.

I also don't agree with a really long time like this for the removal for
the same reason; people will forget then wonder what happened when
things are removed.

Another thing to consider is, upgrading the grub package doesn't change how your
system boots. That change doesn't happen until you run grub-install from
the newer version of grub.

> 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?
 
 Again, I'm not removing sys-boot/grub, so comparing this to removing
 sys-boot/syslinux, sys-boot/lilo etc does not feel right to me.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]