From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D180F138330 for ; Tue, 4 Oct 2016 22:24:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4819AE0B1B; Tue, 4 Oct 2016 22:24:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E1945E0941 for ; Tue, 4 Oct 2016 22:24:41 +0000 (UTC) Received: from localhost (unknown [100.42.103.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id BB0EB34107E for ; Tue, 4 Oct 2016 22:24:39 +0000 (UTC) Date: Tue, 4 Oct 2016 17:24:16 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rfc: the demise of grub:0 Message-ID: <20161004222416.GA17685@whubbs1.gaikai.biz> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20161003215933.GA28448@whubbs1.gaikai.biz> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 07204b95-1a7b-4d39-8020-237ac77aabd4 X-Archives-Hash: f6c876fc66d3192f20e7adc3f001a8ae --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > I want to look into removing grub:0 from the tree; here are my thoughts > > on why it should go. >=20 > I don't disagree with the thought, but have some niggles on the=20 > individual points. Note that I'm not nearly as negative on the idea in= =20 > general as the comments on the individual points may suggest on their own. =20 Why bring them up then? ;-) > > - the handbook doesn't document grub:0; we officially only support > > grub:2. >=20 > That's not a reason to remove grub:0 from the tree. If it was, there's= =20 > many other alternative boot managers that would need removed as well. =20 > Thankfully, gentoo tends to emphasize choice. =3D:^) =20 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. >=20 > Grub:0 can _boot_ a no-multilib system just fine. AFAIK the problem is= =20 > at build time -- a no-multilib system can't *build* grub:0. >=20 > FWIW I run no-multilib myself, but as I switched from a multilib system= =20 > and still had its grub:0 installed and booting when I first went no- > multilib, I know it /boots/ just fine. >=20 > And AFAIK that's actually what grub-static is, a pre-built grub:0 tarball= =20 > with an installer that installs the prebuilt pieces in all the right=20 > places, originally developed IIRC by the gentoo/amd64 folks precisely to= =20 > solve the amd64 no-multilib build problem. =20 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. >=20 > Another alternative would be simply hard-masking it, but leaving it in=20 > place for those who want it. It does still work, and I see no evidence= =20 > 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 =66rom the tree. > > - We have custom patches for grub:0, which will never go upstream. > >=20 > > - grub:0 is dead upstream. They have not done any work on it in years. >=20 > Both valid points. >=20 > But I'll make the same point here as I did on a different proposed=20 > package removal thread recently. General gentoo policy is that a dead=20 > upstream (and lack of a gentoo maintainer) isn't sufficient reason to=20 > remove a package if it still works. As long as it's not broken or a=20 > security issue, the general policy is to leave it in the tree for anyone= =20 > that needs it. =20 As I said above, I'm not removing sys-boot/grub, just the obsoleted versio= n. > So is grub:0 so broken it justifies removal from the tree, despite=20 > 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. >=20 > +100. Good gentoo documentation on properly creating and managing your= =20 > own grub.cfg without their config script would go a long way here. (This= =20 > may already exist, I switched to grub2 while the documentation remained= =20 > quite raw.) =20 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. > >=20 > > 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. >=20 > I'd suggest that this is a sufficiently huge change (comparable in level= =20 > to the openrc upgrade you handled a few years back, tho obviously not as= =20 > wide ranging in terms of other packages affected) for anyone still on=20 > 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=20 > the period, and the traditional 30-day package-masking five months later,= =20 > 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=20 > remains more flexible, even if not as flexible as grub:2. If it's not=20 > more broken, what justifies removal from the tree when lilo and various= =20 > other similar boot manager packages remain? =20 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 --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlf0LAoACgkQblQW9DDEZTgD/ACgmicYOKshAcjQ6aZ1NHOC1DSr jK4AoJGCZIB0Wy13zd4fQdRbIz7u1zC3 =tT09 -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62--