package-mapping with #:deep? #t doesn't get all the implicit inputs

#:deep? #t currently works by interposing a dummy build system that

lowers the package to a bag using the original build system, then

applies the supplied transformation to all of the bag's inputs, then

returns a new bag with the new inputs.

The problem with this approach is that it doesn't affect the bag

arguments. This means that packages passed in as arguments may still

end up being used without being transformed. Worse still, packages

*not* passed in as arguments may end up being used *unless one is

explicitly passed in as an argument*, as is the case with

qt-build-system's #:qtbase argument.

In short, the current approach of having the build-system lower

procedure leave the arguments mostly unchanged and letting the

bag->derivation procedure (the "bag builder") fill in lots of defaults

means that there are implicit inputs that cannot be touched at the

package level without adding special logic for every single build system

that does something like this.

I propose that we have the build system lower procedure (that is, the

one that converts from package to bag) completely fill in the argument

list with all defaults, and we modify build-system-with-package-mapping

to transform all arguments that look like a package or a list of

packages (or maybe even a tree containing packages).

Many large-scale package transformations have their purpose defeated if

even a single package slips through and has to be built or downloaded

separately (e.g. "I wanted to use a more minimal version of P, and now I

have both the original version of P *and* a more minimal version of P

*and* a duplicate copy of a large portion of the package graph..."). In

fact, in some situations, this could cause exponential growth of the

number of packages, e.g. a transformation is applied to qtbase and its

dependencies, but not to the implicit version and its dependencies, so

now all the dependencies of qtbase are duplicated, and if this happens

again at a higher level with something that depends on a package with

qt-build-system, now there are four duplicate subgraphs, and so on.

What do you think?

- Ulf

Ulf Herrman <striness@tilde.club> writes:

Sounds like a good idea to me.

Hello Ulf,

Ulf Herrman <striness@tilde.club> writes:

This is indeed sub-optimal!

[...]

Like Csepp, I like your proposition! I'm CC'ing the core team, in case

they have something to add to it, but otherwise, we only need a

volunteer to turn it into code :-).

--

Thanks,

Maxim

Hi,

On Thu, 31 Aug 2023 at 15:14, Ulf Herrman <striness@tilde.club> wrote:

On principle, this looks a good idea.

Do you already have an implementation? Because transformations lead to

headache and sometimes the implementation is hard, well evil, details

and all that. :-)

Cheers,

simon

This patch series causes package-mapping to recurse into package and bag

arguments when #:deep? #t is given. It also recurses into gexps and

gexp inputs in search of packages to devour. It also ensures that build

systems leave all of their implicit package arguments in the bag

arguments, ready to be found by package-mapping. It also fixes a couple

build system errors I came across while modifying 40+ build systems and

testing a deep package transformation.

- ulfvonbelow

Hello Ulf!

Ulf Herrman <striness@tilde.club> writes:

Nice series!

I've reviewed it, and it makes sense to me. I'd like to apply it to the

core-updates branch. Core team, what say you?

--

Thanks,

Maxim

I've also been using this patch, which rebinds `this-package' within

package variants to refer instead to the variant rather than the

original. When I tried applying a deep transformation to icecat, it

failed to reach icecat-minimal or something like that. Or maybe it was

some input of icecat - might have been my local version of mesa that had

breakage. Anyway, I've since forgotten exactly what happened and why (I

didn't actually write the commit message until quite some time later),

but I do know that this patch fixed it.

I might try to rediscover what the problem was later, but thought it

would be good to make you aware of this so as to hopefully consolidate

world rebuilds.

- Ulf

Ulf Herrman <striness@tilde.club> writes:

I've since done some more checking to recall what the problem actually

was, and it indeed manifested as a combination of an icecat and mesa

problem: the wrap-program phase of icecat-minimal uses

`this-package-input' to get the mesa to point LD_LIBRARY_PATH to.

However, it then stuffs the resulting package inside a <file-append>

object, which we don't currently recurse through, so it ends up

compiling with one mesa and using another at runtime, which somehow

causes a segmentation fault.

Having looked at it again, I'm not sure that rebinding `this-package' is

the best solution - it's certainly not a general solution, since any old

package could be shoved into a <file-append> object (or really any

declarative file-like object) and thereby be hidden from

transformations. My understanding is that packaging guidelines already

discourage directly substituting top-level package references,

preferring instead tools like `this-package-input' so as to work nicely

with transformations. If those guidelines are adhered to, the

aforementioned patch should fix issues of this nature. I'm not sure

what the best way of handling objects like <file-append> and such is,

but as long as package references go through `this-package', it should

only matter for implicit inputs, and I don't think any of them use

declarative file-like objects other than <package>.

After thinking about it some more, I think it would be good if we had a

way of testing to make sure that every package is "transformable": that

is, if you apply a deep transformation to it, and lower the result to a

derivation, at no point within the dynamic extent of that lowering is a

derivation from an untransformed package introduced. This would allow

for testing for transformability en masse, and could be added to 'guix

lint'.

- Ulf

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Sorry for the delay, I’ll provide feedback within a couple of days.

Ludo’.

Hi,

Ulf Herrman <striness@tilde.club> skribis:

Could you send it as a separate issue?

(I think I once reported a bug for this issue, but I can’t find it.)

Ludo’.

Hi Ulf,

Ulf Herrman <striness@tilde.club> skribis:

Could you share an example of what is fixed by these changes?

Let’s take ‘python-itsdangerous’ as an example. It has zero inputs,

only implicit dependencies, yet I can do this:

‘python’ above is an implicit dependency, yet it was suitably replaced

by ‘--with-input’.

In what cases does ‘package-mapping #:deep? #t’ miss implicit inputs?

Thanks,

Ludo’.

Ulf Herrman <striness@tilde.club> skribis:

Aah, now I understand. :-)

It’s indeed the case that arguments can capture references to packages

that won’t be caught by ‘package-mapping’. For instance, if you write:

(package

…

(arguments (list … #~(whatever #$coreutils))))

… then ‘coreutils’ here cannot be replaced.

To address this, the recommendation is to always add dependencies to

input fields and to use self-references within arguments. The example

above should be written like this:

(package

…

(arguments

(list … #~(whatever #$(this-package-input "coreutils")))))

It’s just a recommendation and one can perfectly ignore it, and I

suppose that was the impetus for this patch.

This is one of the things discussed while designing this change:

https://guix.gnu.org/en/blog/2021/the-big-change/

(search for “self-referential records”)

https://issues.guix.gnu.org/49169

My take was and still is that it’s an acceptable limitation. Packagers

need to follow the guideline above if they want proper support for

rewriting, ‘guix graph’, and other tools.

WDYT?

Thanks,

Ludo’.

Hi Maxim,

On Thu, 05 Oct 2023 at 22:36, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Well, I am not sure to deeply understand some details to get all the

implications here, so I have nothing relevant to say. For instance,

from my understanding, the core change is:

and I do not feel enough skilled here for getting the implications.

Equally for this kind of changes:

Therefore, I trust other opinions or I need some time for diving and

filling some gaps.

Cheers,

simon

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

Ulf had mentioned the problems they were facing in the original post of

this issue:

Examples would be an Qt packages, or packages using #:meson

meson-variant.

Any build system accepting package as arguments are subject to this

problem, if I understand correctly.

I hope that helps,

--

Thanks,

Maxim

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

But not all packages found in a bag come from inputs; they may be

provided as an argument to the build system (cmake, meson, qt, etc. all

allow for this).

--

Thanks,

Maxim

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

It's not quite everywhere a package is accepted as an argument: there

are many cases where a package is passed as a package argument but

doesn't end up in the arguments list of the corresponding bag. This is

usually the case because that argument is only overriding a default

package that is just added as an input to the bag, with no special

treatment aside from being an implicit input. For example, #:cmake in

cmake-build-system works this way.

This is however not the case for #:qtbase in qt-build-system, and, much

more prominently, for #:guile. Neither qtbase nor guile are added to

bag inputs implicitly, but they do end up in the final builder, even if

not specified.

Concretely, this looks like this:

---------------------------------

(use-modules (guix packages)

(guix profiles)

(gnu packages base))

(define guile-named-lyle

(package

(inherit (default-guile))

(name "lyle")))

;; contrived example that only replaces hello's immediate dependencies

(define hello-transformer

(package-mapping (lambda (p0)

(if (eq? p0 (default-guile))

guile-named-lyle

p0))

(lambda (p)

(not (eq? p hello)))

#:deep? #t))

(define hello-with-lyle

(hello-transformer hello))

(packages->manifest (list hello hello-with-lyle))

;; $ guix build --derivations --manifest=THISFILE

;; Expectation: build for hello-with-lyle is done with guile-named-lyle.

;; Reality: derivation for hello-with-lyle is the same as hello.

---------------------------------

(and I have confirmed that the above results in guile-named-lyle being

used with the proposed patches applied)

A similar problem manifests when one tries replacing (default-qtbase) in

a package using qt-build-system. Both it and guile are in bag arguments

and not inputs because it's not enough that they be included as inputs,

the builder must also know which one is considered "used by the build

system" if there are multiple. One could argue that this ambiguity also

exists with other build systems - "which cmake should be used, which gcc

should be used", etc - but they choose to resolve it with "eh, whatever

shows up first in PATH matching the required name is probably fine".

It's not unimaginable that there could be cases where explicitly

specifying which package should be used for a particular role would be

necessary, though.

- Ulf

Ludovic Courtès <ludo@gnu.org> writes:

That and a growing thirst for a nuclear option for package rewriting

brought about by trying to debug deep transformations while

simultaneously experimenting with rewriting a manifest of around 270

packages.

There are really several distinct issues at play here:

1. The case of #:qtbase and #:guile being invisible to package-mapping.

This is what I first noticed, and cannot be fixed without modifying

the build systems. This is what prompted looking for packages in

package and bag arguments, and recursing into lists therein (just in

case an argument took a list of packages).

2. The (perceived) case of packages hiding inside arguments. In

hindsight, this was probably actually (3) causing this, though it's

hard to tell because I discovered it last. I attempted to resolve

this by recursing through <gexp>s and <gexp-input>s.

3. `this-package' referring to the inherited package in thunked fields,

rather than the package inheriting them. This is what prompted the

use of package-{inputs,arguments,etc}-with-package.

(1) could be resolved in several ways. I'm partial to looking for

arguments whose values are packages and transforming them (when #:deep?

#t is specified), and adjusting the build systems to make that work

consistently, which is what I've done.

(2) is probably not an issue, though it occurs to me that the technique

of recursively searching through arguments looking for packages could be

used to implement a sort of automated "transformability" check, which

could help a lot when trying to debug transformations.

(3) is a major issue; the entire strategy of using `this-package-input'

to enable transformations breaks because of it. My fix works for me at

least, though it requires exposing additional low-level procedures and

transformation authors using them. I'll open another bug about it, as

requested.

I think it's probably reasonable, though I would like it if there were

tooling in place to detect cases where said guidelines are not

followed, so as to aid in debugging and verifying that a transformation

worked as intended.

- Ulf

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Yes, but these packages (#:cmake for ‘cmake-build-system’, #:python for

‘python-build-system’, etc.) become inputs of the bag, and are taken

into account, as in this example:

(In this case I had to apply the patch below because ‘cmake-minimal’ was

mistakenly marked as hidden which, as implemented by

eee95b5a879b7096dffd533f24107cf8926b621e, meant that it could not be

replaced.)

I gave a similar example with ‘python-build-system’ here:

https://issues.guix.gnu.org/65665#10

My understanding is that understanding is that this patch series is

about addressing cases as I explained above, where ‘arguments’ refer to

packages directly instead of using self references. Do I get this

right, Ulf?

Thanks,

Ludo’.

Hello,

Ulf Herrman <striness@tilde.club> skribis:

On that topic of a catch-all option for rewriting: there’s an unused

procedure called ‘map-derivation’, which performs rewriting at the level

of derivations. It’s harder to use, more expensive, but who knows,

perhaps we’ll find a motivating use case… (Allowing for graph rewriting

has been a major goal for me since the beginning.)

How are #:qtbase and #:guile invisible to package mapping?

They appear in the bag inputs and thus are definitely visible to

‘package-mapping’, as a I showed with the CMake and Python examples in

this thread.

For good measure :-) here’s an example with #:qtbase:

Now, package transformation options are almost all implemented in terms

of ‘package-input-rewriting/spec’, and I have to admit that it’s much

easier to use than ‘package-mapping’. The latter is low-level and it

can be a source of headaches.

Yeah. I think we have to understand that “hiding” is to some extent

inevitable; <package> is more concise than <bag>, which is more concise

than <derivation>. There are extra “inputs” showing up when we go from

one abstraction to the one below.

Ah yes, I agree; I reported it here:

https://issues.guix.gnu.org/50335

I think we can discuss it separately though, in that bug report

probably.

OK.

Yeah, understood.

Thanks,

Ludo’.

Ludovic Courtès <ludo@gnu.org> writes:

"Invisible to package-mapping" was perhaps not the clearest phrasing;

"not completely replaced by package-mapping" might be better. qtbase

does indeed go in the bag inputs, but replacing the bag inputs has no

effect on the bag arguments, and even if we replaced it in the bag

arguments as well, it might not even be in there to begin with, in which

case the bag-builder would introduce a default that is only visible at

the level of derivations.

And if you do a quick 'cat

/gnu/store/paixxkdaakv55bffggxx4l9hiknl8i5r-qgit-2.10.drv'...

------------------------------

Derive

([("out","/gnu/store/z8qrhfmicylxy2mwvcvh9sizfhd3x4d3-qgit-2.10","","")]

,[("/gnu/store/0jk33gpzyicyppbnh458213007v0qjhs-mesa-23.1.4.drv",["out"])

,("/gnu/store/0njvvgjlb52abhqnmb4rx22sfkxm2h9c-gcc-11.3.0.drv",["out"])

,("/gnu/store/0p1sns81qbgr8ayiv02fv4rm5drcycd7-libxdamage-1.1.5.drv",["out"])

,("/gnu/store/14a2ban238fng3c8632lrfkmz54y7m2c-binutils-2.38.drv",["out"])

,("/gnu/store/1n39zcbr528b7rh9bf1pwfrm7mv8nr8m-bzip2-1.0.8.drv",["out"])

,("/gnu/store/2pv3mjjiwh37b0m3m1hijxifnchrw76i-libpciaccess-0.16.drv",["out"])

,("/gnu/store/3fy3bf7wysi1n1qz9jz8xzx11sgy8m6d-git-2.41.0.drv",["out"])

,("/gnu/store/3r0r8j76l0qvxasmb7rgn7lvpikjdyn1-libxdmcp-1.1.3.drv",["out"])

,("/gnu/store/4jfy1ca1d5772z15jcyk1v8wdwdcllbi-gzip-1.12.drv",["out"])

,("/gnu/store/5nvwagz2hphvlax2bnj93smr1rgrzr8l-libx11-1.8.1.drv",["out"])

,("/gnu/store/64vwaah2spd7q66hji6sm1j2fl6pd1rn-diffutils-3.8.drv",["out"])

,("/gnu/store/6k4xxkp725r09vkn7rz2gc50asjjhpkk-xorgproto-2022.2.drv",["out"])

,("/gnu/store/91b6yraa6qax7lq7riqg1ag6lql2gfzi-tar-1.34.drv",["out"])

,("/gnu/store/9kcv1x0lrf6fdck2j42zarxrvjzxxznv-coreutils-9.1.drv",["out"])

,("/gnu/store/9piaq0aaf202r1gq7crig1cr131kx8zn-file-5.44.drv",["out"])

,("/gnu/store/9y28bf3ywai2ybhr92c904s3cxsc8apx-libpthread-stubs-0.4.drv",["out"])

,("/gnu/store/ak17xsjb4zcw7sf0r0lxxiy4xmh57i2h-findutils-4.9.0.drv",["out"])

,("/gnu/store/bmc1hqlb207n1mnf9rs7wy8zh9hhf0br-qgit-2.10-checkout.drv",["out"])

,("/gnu/store/cmd13zzya808ca8siibj8ib3llpkrr3f-sed-4.8.drv",["out"])

,("/gnu/store/cr84vpnszpy3hkwsm8ijwpnkknxvx8k4-grep-3.8.drv",["out"])

,("/gnu/store/cx6ws98i67qf6ba9msz7n63x78ky812c-libxxf86vm-1.1.4.drv",["out"])

,("/gnu/store/f9fdjk1g1s1aqmlmi4clla2kqns7283v-qtbase-6.6.0.drv",["out"])

,("/gnu/store/fpprrvfiqw6g0mn5gb7ac87nbmrsq64l-make-4.3.drv",["out"])

,("/gnu/store/g2z0fvzkh5xl4f00aixchkwxrwbbljlr-libxext-1.3.4.drv",["out"])

,("/gnu/store/gb247cil5nlnx175dhqmgg67q7ng7n2h-which-2.21.drv",["out"])

,("/gnu/store/hb2y5axynnpwqpx1znjsn5azspc9a4lw-module-import-compiled.drv",["out"])

,("/gnu/store/hjhr64r5x3bhdw63zz3a3v09vfrlkhrh-qtbase-5.15.10.drv",["out"])

,("/gnu/store/hvqfl21wx397k58jpn5dpn2l5y5k1dl0-patch-2.7.6.drv",["out"])

,("/gnu/store/kn7kcpkkcvy6gmrc74mf4mq0290dsf94-glibc-2.35.drv",["out","static"])

,("/gnu/store/l3ns54f8vgqmycwi50p5cwbr6l466kj3-libdrm-2.4.114.drv",["out"])

,("/gnu/store/lfsv077ggq8w8cbw86wf1075zhb3bhrw-xz-5.2.8.drv",["out"])

,("/gnu/store/lssiz5ppxfybwmr638x3bcmn4b6ixk89-linux-libre-headers-5.15.49.drv",["out"])

,("/gnu/store/n4p8vzp14k1pkgxyfb5mak12rm1yiwnr-cmake-minimal-3.24.2.drv",["out"])

,("/gnu/store/nldpb7xl1slkiigvr9rax7qhcky5flnc-util-macros-1.19.3.drv",["out"])

,("/gnu/store/nvaxgm6jvjy6agmp89ivahz7z9vl3ldh-libxcb-1.15.drv",["out"])

,("/gnu/store/pdkcmkk5h3zq82ws9fps4bxnfmsmz0kx-libxshmfence-1.3.drv",["out"])

,("/gnu/store/s5nyfh0cd3z9wsk69c9blj5y850kvvcm-libvdpau-1.5.drv",["out"])

,("/gnu/store/swblndkq2c4rzyv3xfkmsa4cjf6abphf-ld-wrapper-0.drv",["out"])

,("/gnu/store/vkns1vij5hjamh7dpd74zs5203526747-libxfixes-6.0.0.drv",["out"])

,("/gnu/store/w2mnryfds1bd7wyyqmdi0kblz0dym1bx-glibc-utf8-locales-2.35.drv",["out"])

,("/gnu/store/wwmk0rrnb5q8f48fm7h6grzar5qmslgi-libxau-1.0.10.drv",["out"])

,("/gnu/store/xwckz4hbfydkfiiaa7bgslbh317gdkiq-bash-minimal-5.1.16.drv",["out"])

,("/gnu/store/z7fxw9jj7avcr1ng88pak3ds3kxbfy15-gawk-5.2.1.drv",["out"])

,("/gnu/store/zraigp7miin3vzr5dcbr4i9rvds0i07r-guile-3.0.9.drv",["out"])]

,["/gnu/store/2lg0ibv3vw01xc83advvrhvmc8yxbhh0-qgit-2.10-builder","/gnu/store/p173g6kxa69qaypf8dvnw1ismd8g4k8q-module-import"]

,"x86_64-linux","/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/p173g6kxa69qaypf8dvnw1ismd8g4k8q-module-import","-C","/gnu/store/nl9dadzfmjm9wg7v3r31jkx773dl683x-module-import-compiled","/gnu/store/2lg0ibv3vw01xc83advvrhvmc8yxbhh0-qgit-2.10-builder"]

,[("out","/gnu/store/z8qrhfmicylxy2mwvcvh9sizfhd3x4d3-qgit-2.10")])

---------------------------

you'll see we have both a

("/gnu/store/f9fdjk1g1s1aqmlmi4clla2kqns7283v-qtbase-6.6.0.drv",["out"])

and a

("/gnu/store/hjhr64r5x3bhdw63zz3a3v09vfrlkhrh-qtbase-5.15.10.drv",["out"])

in use.

(and if this were a transformation that applied to all packages, it

would be using two variants of the entire world beneath qtbase also)

Ideally no new packages would be introduced when going from bags to

derivations - there is also information at the package level that is

missing at the derivation level, like properties and arguments, that

transformations should be able to access.

Ah, in the meantime I created issue #66510. I suppose I should merge

that. I think the syntactic option presented there seems promising -

extending record constructors so that (inherit parent) can be replaced

with (inherit parent (fieldname variable-like-macro-name) ...) to cause

uses of variable-like-macro-name within the constructor to refer to the

parent's value of fieldname, with any field thunk of the parent

evaluated while `this-package' is bound to the package being defined.

- Ulf

Hi,

Ulf Herrman <striness@tilde.club> skribis:

[...]

D’oh! Now we have a bug to chew. (Sorry if this was obvious to you

from the start; it wasn’t to me!)

I don’t know, should we start by having a proper bug report for this and

study how this happen?

Again I’m sorry if I’m slow to understand, but I’d like to make sure we

have a good understanding of the problem before we start discussing

solutions.

Thanks,

Ludo’.

severity 65665 important

quit

Ludovic Courtès <ludo@gnu.org> writes:

Does that mean opening a new issue, or what? The bug you've described

is the one this issue was initially opened for.

Okay, I suppose I should have given a concrete example of the behavior.

The qgit example can fill that role:

$ cat $(./pre-inst-env guix build qgit -n --derivations --no-grafts --with-latest=qtbase)

<observe that an untransformed qtbase is present>

The way this happens is that qt-build-system's bag-builder

(e.g. qt-build, qt-cross-build)) introduces a reference to the qtbase

from its #:qtbase argument into the gexp it creates a derivation from,

completely independently of any inputs. qgit doesn't explicitly specify

#:qtbase, and qt-build-system's 'lower' procedure doesn't add one, so

the default value for that keyword argument, (default-qtbase), is used

in qt-build.

This default value can only be overridden by explicitly passing #:qtbase

as a package or bag argument. This requirement doesn't map well to a

generic package transformation interface at all - it requires that every

transformer (e.g. package-mapping) check if the package it's

transforming is using qt-build-system, and if so explicitly supply a

#:qtbase that is the result of transforming the original implicit or

explicit value, after somehow figuring out what that may be (currently

only doable by manually reading guix/build-system/qt.scm).

This behavior is also currently exhibited by all build systems' handling

of #:guile. Here's a concrete example of that, taken from another

mailing I sent to this issue (https://issues.guix.gnu.org/65665#15):

---------------------------------

(use-modules (guix packages)

(guix profiles)

(gnu packages base))

(define guile-named-lyle

(package

(inherit (default-guile))

(name "lyle")))

;; contrived example that only replaces hello's immediate dependencies

(define hello-transformer

(package-mapping (lambda (p0)

(if (eq? p0 (default-guile))

guile-named-lyle

p0))

(lambda (p)

(not (eq? p hello)))

#:deep? #t))

(define hello-with-lyle

(hello-transformer hello))

(packages->manifest (list hello hello-with-lyle))

;; $ guix build --derivations --manifest=THISFILE

;; Expectation: build for hello-with-lyle is done with guile-named-lyle.

;; Reality: derivation for hello-with-lyle is the same as hello.

---------------------------------

Hopefully that makes it clear why this is happening.

As for solutions, some options that come to mind:

1. guile and qtbase, instead of being passed to bag builders as a

separate argument, are passed as a bag input that is looked up by

magic input label, e.g. "guile-for-build", "qtbase-for-build", etc.

Seems fragile, but requires no changes to package-mapping, etc.

2. Modify the build systems so that these kinds of implicit arguments

that are packages are always present in bags, and the defaults for

those keyword arguments in e.g. qt-build are never used. This is the

approach I've taken with

https://issues.guix.gnu.org/issue/65665/attachment/4/0/3. This still

requires that bag arguments that are packages are transformed in

addition to inputs.

I hope that counts as a proper bug report.

- Ulf

Hi,

On Sat, 21 Oct 2023 at 17:22, Ulf Herrman <striness@tilde.club> wrote:

[...]

If I might, Guix revision a25a492f2b, my understanding is,

$ ./pre-inst-env guix build qgit -n --with-latest=qtbase

/gnu/store/gx5d03as0k1w6jv0pssi6j69n8glf6w5-qgit-2.10.drv

/gnu/store/h02aizdjy4p10n4gmcy0y35x14lmjx3n-qtbase-6.6.0.drv

Then the builder of the derivation

/gnu/store/gx5d03as0k1w6jv0pssi6j69n8glf6w5-qgit-2.10.drv reads,

Therefore, the transformation does not rewrite #:qtbase. And note that

qtbase-5.15.10 is not listed as #:inputs.

Without the transformations, it reads,

Cheers,

simon