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

> I don’t know, should we start by having a proper bug report for this and
> study how this happen?

Does that mean opening a new issue, or what?  The bug you've described
is the one this issue was initially opened for.

> 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.

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