From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GAVBKcLws1//AQAA0tVLHw (envelope-from ) for ; Tue, 17 Nov 2020 15:48:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id oFU6JcLws1/cDAAA1q6Kng (envelope-from ) for ; Tue, 17 Nov 2020 15:48:18 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2B88C9403AD for ; Tue, 17 Nov 2020 15:48:18 +0000 (UTC) Received: from localhost ([::1]:38504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kf3DM-0003iP-Oc for larch@yhetil.org; Tue, 17 Nov 2020 10:48:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf3D8-0003hX-LM for guix-patches@gnu.org; Tue, 17 Nov 2020 10:48:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:49386) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kf3D8-0001TY-CJ for guix-patches@gnu.org; Tue, 17 Nov 2020 10:48:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kf3D8-0004p0-Bq for guix-patches@gnu.org; Tue, 17 Nov 2020 10:48:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#41066] [PATCH] gnu: bootloader: Support for chain loading. Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 17 Nov 2020 15:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41066 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Stefan Cc: 41066@debbugs.gnu.org, Mathieu Othacehe , Efraim Flashner , Maxim Cournoyer Received: via spool by 41066-submit@debbugs.gnu.org id=B41066.160562808118527 (code B ref 41066); Tue, 17 Nov 2020 15:48:02 +0000 Received: (at 41066) by debbugs.gnu.org; 17 Nov 2020 15:48:01 +0000 Received: from localhost ([127.0.0.1]:60932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kf3D6-0004ok-VU for submit@debbugs.gnu.org; Tue, 17 Nov 2020 10:48:01 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:47288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kf3D5-0004oc-GU for 41066@debbugs.gnu.org; Tue, 17 Nov 2020 10:48:00 -0500 Received: from localhost (80-110-126-103.cgn.dynamic.surfer.at [80.110.126.103]) by dd26836.kasserver.com (Postfix) with ESMTPSA id D29453363365; Tue, 17 Nov 2020 16:47:57 +0100 (CET) Date: Tue, 17 Nov 2020 16:47:55 +0100 From: Danny Milosavljevic Message-ID: <20201117164755.1a27422b@scratchpost.org> In-Reply-To: References: <7A4ABEA8-4500-4D55-BCCE-BFB37FB06B2C@vodafonemail.de> <20200524131316.4c6e8a50@scratchpost.org> <3197004D-0131-4781-99FD-60EBE434E794@vodafonemail.de> <023CBBED-35CD-4AD3-97C4-0DE0B7623B9A@vodafonemail.de> <6E5ECFBA-57F4-485F-9403-1D04CF82062D@vodafonemail.de> <4D71A75A-5722-457C-A5CE-98CE51A53450@vodafonemail.de> <975EC414-6A81-444B-9BB0-AE303C6A9511@vodafonemail.de> <20201116103346.55ff8422@scratchpost.org> X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/13Pxte/5tFF31QVpcSmkxIC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.7 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.39 X-TUID: gltlABxyOh51 --Sig_/13Pxte/5tFF31QVpcSmkxIC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Stefan, oops. I've reviewed and pushed the first part (s;HOOK;HOOKS;) now as guix master commit ede4117f7f18e118003f2599f5c8e985dfbdf9a5. But I'm not sure whether the COPY-FILES? thing is a nice API (and I mean no= t just the flag). I would prefer if the user would just change the INSTALLER in the case he w= ants to not use the profile (which is kinda weird?!) or pack it or whatever. In case the user wanted to index the profile content, the user would use a = HOOK to do that. It really depends on what exactly efi-bootloader-chain is being presented a= s. Is it a profile ? Then it shouldn't have weird flags like that--if possible--and instead use the standard methods. For example you could do instead (I cut&pasted to show the idea--untested!): (define* (efi-bootloader-chain files final-bootloader #:key (hooks '()) installer) (let* ((final-installer (or installer (lambda (bootloader target mount-point) ((bootloader-installer bootloader) bootload= er target mount-point) (let* ((mount-point/target (string-append mount-point target)) ;; When installing Guix, it's common to mount TARGET b= elow ;; MOUNT-POINT rather than below the root directory. (bootloader-target (if (file-exists? mount-point/targe= t) mount-point/target target))) (when (eq? (and=3D> (stat bootloader-target #f) stat:type) 'directory) (copy-recursively (string-append bootloader "/collection") bootloader-target #:follow-symlinks? #t #:log (%make-void-port "w"))))))))))))) (profile (efi-bootloader-profile files (bootloader-package final-bootloa= der) (if (list? hooks) hooks (list hooks))))) (bootloader (inherit final-bootloader) (package profile) (installer #~(lambda (bootloader target mount-point) (#$final-installer bootloader target mount-point)))) This way the weird flag COPY-FILES? is gone with no loss of functionality to the customizer. It's possible for the customizer to read the bootloader package (profile), so it's still possible to copy stuff if it's required (pass a custom INSTALLER which does the copying and also some custom installation). I have a few questions: (1) Why is there a $output/collection subdirectory? Is there something else than that in the profile output? =20 If there are no good reasons to do it like that, I'd just put the profile into $output directly instead--it's easier to understand, and also = it's how other profiles are being used. (2) The COPY-FILES? flag is kinda weird. I would prefer if INSTALLER just defaulted to a procedure that: does copy files, and then calls the final bootloader installer. If the user doesn't want it then the user could still pass a INSTALLER that doesn't (for example the user could pass #:installer (bootloader-installer final-bootloader)). (3) Why isn't the final bootloader installed last? I would have expected it to be installed last so that if it does packing of the profile contents in order to quickly find it at boot, it would have to have all the files of the profiles already, no? Could you explain what this is for in your use case? I don't yet understand the reason for this complexity. --Sig_/13Pxte/5tFF31QVpcSmkxIC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+z8KsACgkQ5xo1VCww uqWa5gf/VmU7x4rkms0UMJ6IWEzMb9yceeIDKu2HjNpFNE+ln2EE+MWmKqIa2YjL 3goybNtIQyuoThocU0ej2niTjZR0LFT7Bf3tENjYQyX+WKCrk01jM+F5jmoiNFNW g0vKB5KPrXB2hql6cZyEbpy0pviwNeGACjIY98z5Kv3Ufdv6l1Vuj1tJa8NJrdDe b3YLi8QqfjNNI+W/4V2yjbS13WutguqfvI4bDqiXFqd7347YIJzi9ovIhLK9izY7 1BqZ0YRGqoz6foLLbXPnEkqXtJn8jx08USx6Unib2QPETKjnF36JvKocn+xnQXKA 1od3TWJX1gafKkjdhy+Tg37ytJyKIg== =ut6R -----END PGP SIGNATURE----- --Sig_/13Pxte/5tFF31QVpcSmkxIC--