bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Csepp
Subject: bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs
Date: Fri, 01 Sep 2023 20:08:53 +0200

Ulf Herrman <striness@tilde.club> writes:

> [[PGP Signed Part:Undecided]]
> #: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
>
> [[End of PGP Signed Part]]

Sounds like a good idea to me.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]