From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VvDsv-0001pd-D2 for mharc-grub-devel@gnu.org; Mon, 23 Dec 2013 17:22:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvDsk-0001ol-Vl for grub-devel@gnu.org; Mon, 23 Dec 2013 17:21:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvDsc-0003dZ-Hu for grub-devel@gnu.org; Mon, 23 Dec 2013 17:21:50 -0500 Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:62969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvDsc-0003bz-6u for grub-devel@gnu.org; Mon, 23 Dec 2013 17:21:42 -0500 Received: by mail-ea0-f173.google.com with SMTP id o10so2586038eaj.32 for ; Mon, 23 Dec 2013 14:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=1+aubzVrHRt6U4ZIiNdBPJXM4nEIlbf9fLYmGN3lWa8=; b=DKffUilYijI7Hj/UADLDfPLMw218DD51Odiy3pOixtcAHTYw70n4/jmUDdc1z6MFyE Jces/pkNb2NH3o9ZyDGBQJctU70J4ecAZPIJMO9nSm+Ta6KV4qEbIhdXXqD5z9K0YZvr xiifbIEXgMoOfd9+BWTmobNxORzF29SvRIfgpoKe+ynIVwRdETVTIynL7K0Dz6cSkQbU Uvtkigsj8x0SCNDKvDcVhyo3kny5exm4jKOh/omIn5WboGuKvA0Cd3JHe4qHFoQyRDQX Ue6jQ60MHZ3LqSQ0YSocyP/VIf2HQV8XnGaEIBtxRR7JjnUCIxmyyxroWqZJCild1mPM Tl+w== X-Received: by 10.15.110.8 with SMTP id cg8mr23114388eeb.42.1387837300831; Mon, 23 Dec 2013 14:21:40 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id p45sm49515450eeg.1.2013.12.23.14.21.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Dec 2013 14:21:39 -0800 (PST) Message-ID: <52B8B772.9040007@gmail.com> Date: Mon, 23 Dec 2013 23:21:38 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Breakage from grub-mkconfig changes for grub-file References: <20131223220141.GA25169@riva.ucam.org> In-Reply-To: <20131223220141.GA25169@riva.ucam.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8JLjaT80xUCuhjc1ovlX90NaoQ5xkpomU" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22d X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 22:21:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8JLjaT80xUCuhjc1ovlX90NaoQ5xkpomU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23.12.2013 23:01, Colin Watson wrote: > ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes t= o > grub-mkconfig, which among other things arranged to run all but a > hardcoded list of grub.d scripts once for each of several platforms wit= h > their output enclosed in an "if" block. I do not feel that this change= > was well-thought-out, and I think it should be rethought or reverted > before 2.02. I didn't see anything about it here in advance - did I > miss a thread? >=20 > The problems I have with it are illustrated by its effects on the Debia= n > patch. I must emphasise that I don't think this is unique to the case > of distributions with non-trivial patch sets, and that it's also likely= > to affect users who have made reasonable changes to /etc/grub.d/ locall= y > (as they're entitled to do); distributions are just a useful > early-warning system here. >=20 > 1) Awkward hardcoded list; poor configurability >=20 > 00_header, 30_os-prober, 40_custom, and 41_custom are run only once. > The Debian patch set has an additional script which is not > platform-dependent and should be run only once, namely > 05_debian_theme, so I had to add another case here. Users will surel= y > have other such files; not only do they have to know on upgrade that > they need to take care of this, but they have no recourse that doesn'= t > involve editing $prefix/bin/grub-mkconfig, which is not a file that > should normally be edited by the system administrator; changes to tha= t > file will not normally persist on upgrades. >=20 > This should be redesigned so that there is some way to declare in a > grub.d script that it requires multi-platform support and should be > run multiple times. (It *must* be this way round so that upgrades > work properly.) >=20 The idea was that platform-independent scripts were still runnable, they'll just produce the same output N times and this list is just an optimisations, specially to avoid running os-prober N times. The alternative will be to have something along the lines of different hashbang or implementing this functionality as sh functions. > 2) Strange ad-hoc platform names >=20 > The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen= > mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the > platform names used in the GRUB build system, but yet they're exporte= d > across the interface to /etc/grub.d/ as GRUB_PLATFORM. This is messy= > and confusing, and it's not clear what promises we make about future > changes here. >=20 > We should rationalise this before issuing anything as part of a stabl= e > release, perhaps by adopting the same target_cpu/platform terminology= > used in the build system. Furthermore, if we made the namespaces > match up then it would be fairly straightforward to only run grub.d > scripts for platforms for which we have installed GRUB modules, which= > seems as though it would be sensible. >=20 GRUB platform names don't match with the OS compatibility. On x86 other than xen you can use the same kernel on all the platforms. On ARM, for what is arm-uboot platform for us may require different kernels for different hardware. > 3) Breaks function definitions >=20 > In the GRUB script language, "function" is only permitted at the top > level. This may be an oversight since bash doesn't share this > restriction and GRUB script generally tries to look like bash; > nevertheless it exists today. Part of the Debian patch set causes > 10_linux to emit a function definition, which now causes a syntax > error. >=20 > I think my preferred fix here would be to implement functions other > than at the top level, but it seems a bit rash to try to cram that > into 2.02. >=20 Ok. > 4) Smaller bugs >=20 > Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb,= > I'm pretty sure that the condition for the "x86" platform is buggy; > shouldn't it have an extra "-a" in there? This sort of thing makes m= e > worried about the level of testing these changes have had. >=20 Nice catch. > The grub-file tool seems reasonable and useful to me, but can we just > revert the grub-mkconfig parts of these changes until after 2.02 so tha= t > the effects of these interface changes can be considered more carefully= ? I think it's good to move it to "next", together with --root-directory functionality of grub-mkconfig. Paulo Flabiano Smorigo wanted this feature badly. Unless he has striking arguments why 2.02 needs it, I'm ok with moving this to "next". --8JLjaT80xUCuhjc1ovlX90NaoQ5xkpomU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlK4t3IACgkQmBXlbbo5nOtmBgEAnZEM/CiiHiY0DlAT0LJ09VlW 4qW1hMPY0vsE0JAuBU8BAJNkczZJSvbqrc3u47u3iKTkmIJp4Fh34vZHxWKfWix0 =BgkM -----END PGP SIGNATURE----- --8JLjaT80xUCuhjc1ovlX90NaoQ5xkpomU--