Re: Problem with texlive-default-updmap.cfg

[Ricardo Wurmus]

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

> Hello!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> The invoking Guix on the other hand should always be what the user
>> expects.  It is used through (guix inferior) only.
>>
>> This error indicates to me that a *new* Guix (e.g. the invoking Guix)
>> somehow ends up accessing an *old* Guix (e.g. the library Guix).  My
>> thinking is that the invoking Guix is asked to build a profile, then
>> builds the profile hook for TeX Live packages, and then somehow looks
>> *outside* of the invoking Guix for that package.
>>
>> The profile hook does perform a lazy package lookup with this:
>>
>> (define updmap.cfg
>>     (module-ref (resolve-interface '(gnu packages tex))
>>                 'texlive-default-updmap.cfg))
>>
>> I wonder if that ends up being evaluated outside of the inferior
>> somehow.  That would be quite a bummer.
>
> Not sure I understand the context well enough, but yes,
> ‘texlive-font-maps’ in (guix profiles) uses packages from the host Guix,
> not from an inferior (it cannot know that inferiors are being used).
>
> Does that lead it to build incorrect font maps or things like that?

Worse: there’s a mismatch between what one Guix wants and what the other
offers.  Apparently the profile hook from the newer Guix is used, but
the look up of texlive-default-updmap.cfg in (gnu packages tex) happens
in the older Guix — which doesn’t *have* that package — and thus fails.

> Would it help to change ‘texlive-font-maps’ to use
> ‘manifest-lookup-package’ instead to find its ‘updmap.cfg’ package?
> This is what several other hooks do, precisely to make sure they pick
> the matching package.

Maybe.  I’ll see if wa can change this and if it makes a difference.
Thanks for the input!

-- 
Ricardo