unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: gwl-devel@gnu.org, Ontje.Luensdorf@dlr.de
Subject: Re: Problem with texlive-default-updmap.cfg
Date: Sun, 27 Feb 2022 18:32:26 +0100	[thread overview]
Message-ID: <87v8x0uset.fsf@gnu.org> (raw)
In-Reply-To: <87pmnd9jc7.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Wed,  23 Feb 2022 23:15:33 +0100")

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?

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.

HTH!

Ludo’.


  reply	other threads:[~2022-02-27 17:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  9:37 Problem with texlive-default-updmap.cfg Ontje.Luensdorf
2022-02-23 15:08 ` Ricardo Wurmus
2022-02-23 22:15   ` Ricardo Wurmus
2022-02-27 17:32     ` Ludovic Courtès [this message]
2022-02-27 17:48       ` Ricardo Wurmus
2022-02-28 11:01         ` zimoun
2022-02-28 11:42         ` Ludovic Courtès
2022-02-28 13:17           ` Ricardo Wurmus
2022-02-28 13:15       ` Ricardo Wurmus
2022-03-30 12:32 ` Ricardo Wurmus
2022-03-31  6:31   ` Ontje.Luensdorf
2022-03-31  7:31     ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.guixwl.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8x0uset.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=Ontje.Luensdorf@dlr.de \
    --cc=gwl-devel@gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).