all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: 61363@debbugs.gnu.org
Subject: [bug#61363] [PATCH 2/2] self: Apply grafts to the outputs of the guix derivation.
Date: Wed, 22 Feb 2023 10:16:14 +0100	[thread overview]
Message-ID: <87sfey9i1t.fsf@gnu.org> (raw)
In-Reply-To: <20230208075403.11788-2-mail@cbaines.net> (Christopher Baines's message of "Wed, 8 Feb 2023 08:54:03 +0100")

Hi,

Christopher Baines <mail@cbaines.net> skribis:

> Rather than having grafts apply to the derivation itself. This moves grafting
> here to work like grafting for packages, where you can think of the grafted
> outputs as a transformed variant of the ungrafted outputs.

Hmm.

> I'm looking at this as it'll allow the Guix Data Service to compute the
> derivations without grafts, and for these to be useful for substitutes
> regardless of whether users are using grafts.

How does it help exactly?  By disabling grafts in that context?

> +++ b/guix/self.scm
> @@ -752,7 +752,8 @@ (define* (compiled-guix source #:key
>                          (gzip (specification->package "gzip"))
>                          (bzip2 (specification->package "bzip2"))
>                          (xz (specification->package "xz"))
> -                        (guix (specification->package "guix")))
> +                        (guix (specification->package "guix"))
> +                        (graft? #t))
>    "Return a file-like object that contains a compiled Guix."
>    (define guile-avahi
>      (specification->package "guile-avahi"))
> @@ -802,6 +803,12 @@ (define dependencies
>                        guile-json guile-semver guile-ssh guile-sqlite3
>                        guile-lib guile-zlib guile-lzlib guile-zstd)))
>  
> +  (define packages
> +    (cons* gzip
> +           bzip2
> +           xz
> +           dependencies))
> +

[...]

> +         (let ((obj (built-modules (lambda (node)
> +                                     (list (node-source node)
> +                                           (node-compiled node))))))
> +           (if graft?
> +               (explicit-grafting obj packages)
> +               obj)))

There are two things I’m not comfortable with:

  1. Having <explicit-grafting> in (guix packages); it looks misplaced.

  2. More importantly, manually listing packages that might require
     grafting looks like a slippery slope (“oops! we’re not getting the
     GnuTLS graft for that CVE, too bad”).

I designed and implemented several variants to try and delay grafting.
One of them consisted in carrying graft information in gexps:

  https://git.savannah.gnu.org/cgit/guix.git/log?h=wip-gexp-grafts

It’s kinda similar to what you’re proposing in that graft information is
carried as far as possible.  The main difference is that it’s automated.

Hmm needs more thought.

Ludo’.




  reply	other threads:[~2023-02-22  9:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08  7:46 [bug#61363] [PATCH 0/2] self: Apply grafts to the outputs of the guix derivation Christopher Baines
2023-02-08  7:54 ` [bug#61363] [PATCH 1/2] packages: Add explicit-grafting record type to assist with grafts Christopher Baines
2023-02-08  7:54   ` [bug#61363] [PATCH 2/2] self: Apply grafts to the outputs of the guix derivation Christopher Baines
2023-02-22  9:16     ` Ludovic Courtès [this message]
2023-02-22 11:17       ` Christopher Baines
2023-02-28 15:47         ` Christopher Baines
2023-04-17 15:06           ` Christopher Baines
2023-02-10  9:16 ` [bug#61363] [PATCH 0/2] " Christopher Baines
2023-02-28 15:47 ` [bug#61363] [PATCH v2 1/3] packages: Export guile-for-grafts Christopher Baines
2023-02-28 15:47   ` [bug#61363] [PATCH v2 2/3] self: Restructure accessing packages Christopher Baines
2023-02-28 15:47   ` [bug#61363] [PATCH v2 3/3] self: Apply grafts to the outputs of the guix derivation Christopher Baines
2023-04-17 14:59 ` [bug#61363] [PATCH v3] " Christopher Baines
2023-05-16 13:25   ` Simon Tournier
2023-06-03 11:41     ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sfey9i1t.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=61363@debbugs.gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.