Re: Problem with texlive-default-updmap.cfg

[Ricardo Wurmus <rekado@elephly.net>]

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

> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>>> 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.
>
> You mean the ‘module-ref’ above happens in the inferior’s module?

No, the other way around: the profile hook from the inferior is used
(which requires a recently added package), but the module-ref does not
happen in the context of the inferior.  It happens in the context of the
*old* Guix (the “library Guix”), which does not have that package.

> That’s not possible, unless there’s some extra load path trickery going
> on.

Oh, you bet there’s load path trickery going on!
guix/extensions/workflow.scm sets the load path such that the Guix
modules at runtime are those of the Guix library at build time.

> Do you have a simple reproducer?

Not yet, but I’ll try to build one.

-- 
Ricardo