[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: |
Sun, 27 Feb 2022 18:48:18 +0100 |
User-agent: |
mu4e 1.6.10; emacs 28.0.50 |
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