[Top][All Lists]

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

Re: Problem with texlive-default-updmap.cfg

From: Ricardo Wurmus
Subject: Re: Problem with texlive-default-updmap.cfg
Date: Mon, 28 Feb 2022 14:17:44 +0100
User-agent: mu4e 1.6.10; emacs 28.0.50

Ludovic Courtès <> writes:

> Hi,
> Ricardo Wurmus <> skribis:
>> Ludovic Courtès <> 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.


reply via email to

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