GNU bug report logs - #71941
Broken `map-derivation' procedure

Previous Next

Full log

View this message in rfc822 format

From: Sergio Pastor Pérez <sergio.pastorperez <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>, Tobias Geerinckx-Rice <me <at> tobias.gr>, 71941 <at> debbugs.gnu.org, Christopher Baines <guix <at> cbaines.net>, Sergio Pastor Pérez <sergio.pastorperez <at> outlook.es>
Subject: bug#71941: Broken `map-derivation' procedure
Date: Sat, 01 Mar 2025 20:39:45 +0100

Hello, Ludo!

Ludovic Courtès <ludo <at> gnu.org> writes:
> We you able to test this on meaningful cases?

I would test it for rewriting a complete OS with alternative graphic
drivers, but I don't completely understand how a derivation is computed.

For example, the `supertux' package has the `mesa' package as input, I
would expect that the derivation of the `mesa' package would be
contained in the `supertux' derivation inputs.

This code illustrates that this is not the case:
--8<---------------cut here---------------start------------->8---
(use-modules (guix store)
             (guix packages)
             (guix derivations)
             (gnu packages gl)
             (gnu packages games))

(with-store store
  (values (filter (lambda (drv)
                    (equal? (string-append (package-name mesa) "-" (package-version mesa))
                            (derivation-name (derivation-input-derivation drv))))
                  (derivation-inputs (package-derivation store supertux)))
          (package-derivation store mesa)))
--8<---------------cut here---------------end--------------->8---

The above code filters all `mesa' derivations from the `supertux'
derivation inputs, and returns them as the first value, it also returns
the derivation of the `mesa' package. Evaluating the code yields the
following result:
--8<---------------cut here---------------start------------->8---
$9 = (#<<derivation-input> drv: #<derivation /gnu/store/7fsqc78lxp1jsclyl9rjpia9axk2wbq7-mesa-24.3.2.drv => /gnu/store/fmvqq46l2bqgby8ci87by8ycn51nc6x2-mesa-24.3.2-bin /gnu/store/s06dfjxf2sg12airxma7yyjjfa6y7mak-mesa-24.3.2 7ff44156c460> sub-derivations: ("out")> #<<derivation-input> drv: #<derivation /gnu/store/g0ys6y85xixv4bha8vh84gav47ci9fb0-mesa-24.3.2.drv => /gnu/store/g1rwi3s1xrz4swlz97szqmzd5w171p76-mesa-24.3.2 7ff4400705f0> sub-derivations: ("out")>)
$10 = #<derivation /gnu/store/jn8kxv3hvafb0s5xfrk304c57f6r3pkj-mesa-24.3.2.drv => /gnu/store/4ki84lapkja3zkca9gcvsbnh28rlk2wf-mesa-24.3.2-bin /gnu/store/cdw9y91nrfw2pwyycj69wj2kz7jw336w-mesa-24.3.2 7ff4406e2be0>
--8<---------------cut here---------------end--------------->8---

As you can see, the inputs of the `supertux' derivation contain a
different derivation from the one that the `mesa' package returns. I
don't know if this is related to grafting.

Since I don't see how a package translates to a derivation, I cannot map
`mesa' to a different package system wide using `map-derivation'. I
would expect packages to map 1:1 with output derivations.

Please, could anyone shed some light on this confusion?


Best regards,
Sergio.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.