* [gentoo-dev] Re: rfc: the demise of grub:0
@ 2016-10-04 20:44 99% ` Duncan
0 siblings, 0 replies; 1+ results
From: Duncan @ 2016-10-04 20:44 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2016-10-03 21:59 [gentoo-dev] rfc: the demise of grub:0 William Hubbs
2016-10-04 20:44 99% ` [gentoo-dev] " Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox