bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages

[Maxim Cournoyer]

Hi Ludovic,

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

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hi!
>>>
>>> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)
>>
>> Did you checked with Ricardo?  They were the author of that hook, per
>> git blame :-).
>
> I didn’t even look at ‘git blame’, I thought you were the one behind
> this iteration :-), but Ricardo and I discussed it briefly on IRC.
> Anyway, extending Cc!
>
>>> There are probably two things to fix:
>>>
>>>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>>>      passed to ‘union-build’.
>>
>> I think this is the problem to fix.  It's non-intuitive that
>> manifest-lookup-package transitively looks for things instead of looking
>> at the profile.  I actually got tripped by that as well when I authored
>> gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
>> file that reads:
>>
>>              ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
>>              ;; every input referenced by the manifest, while MANIFEST-INPUTS
>>              ;; only retrieves the immediate inputs as well as their
>>              ;; propagated inputs; to avoid causing an empty output 
>> derivation
>>              ;; we must ensure that the inputs contain at least one
>>              ;; loaders.cache file.  This is why we include gdk-pixbuf or
>>              ;; librsvg when they are transitively found.
>>
>> I think we need a 'manifest-lookup-inputs' or similar that stops at the
>> profile, to work at the same depth as manifest-inputs.  Then it wouldn't
>> find texlive-base and the hook wouldn't run (and fail).
>
> There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
> was to take whichever glib/GDK we’d find in the dependency graph, and
> pick the command we need from it.  That way, we wouldn’t introduce any
> additional dependency.  That was the reasoning.
>
> Thinking about, this particular case might be easier: we can make things
> consistent like so:
>
> diff --git a/guix/profiles.scm b/guix/profiles.scm
> index 03333785f9..41f3e25bb3 100644
> --- a/guix/profiles.scm
> +++ b/guix/profiles.scm
> @@ -1786,6 +1786,8 @@ (define entry->texlive-input
>             (cons (gexp-input thing output)
>                   (append-map entry->texlive-input deps))
>             '()))))
> +  (define texlive-inputs
> +    (append-map entry->texlive-input (manifest-entries manifest)))
>    (define texlive-bin
>      (module-ref (resolve-interface '(gnu packages tex)) 'texlive-bin))
>    (define coreutils
> @@ -1809,8 +1811,7 @@ (define build
>            ;; that TeX live can resolve the parent and grandparent directories
>            ;; correctly.  There might be a more elegant way to accomplish 
> this.
>            (union-build "/tmp/texlive"
> -                       '#$(append-map entry->texlive-input
> -                                      (manifest-entries manifest))
> +                       '#$texlive-inputs
>                         #:create-all-directories? #t
>                         #:log-port (%make-void-port "w"))
>  
> @@ -1867,7 +1868,7 @@ (define build
>                (install-file (string-append b "/ls-R") a))))))
>  
>    (mlet %store-monad ((texlive-base (manifest-lookup-package manifest 
> "texlive-base")))
> -    (if texlive-base
> +    (if (and texlive-base (pair? texlive-inputs))
>          (gexp->derivation "texlive-font-maps" build
>                            #:substitutable? #f
>                            #:local-build? #t
>
>
> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
> graph) *and* we have texlive-* packages in the manifest.

That is equivalent, but it doesn't address the core problem in my
opinion.  There's no use to run hooks for things which aren't propagated
at the level of the profile, I think.  If texlive-base in is the
profile, the person wants to use tex and friends.  But if it's wrapped
by some package deep down, we shouldn't care.

I see it the same way as when using libraries and compilers in a
profile; the compiler (consumer) needs to be present else no search path
is created.

Does it make sense?

-- 
Thanks,
Maxim