unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Ricardo Wurmus <rekado@elephly.net>, 63043@debbugs.gnu.org
Subject: bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages
Date: Mon, 24 Apr 2023 23:15:35 +0200	[thread overview]
Message-ID: <878reh0yo8.fsf@gnu.org> (raw)
In-Reply-To: <87zg6yt6ro.fsf@gmail.com> (Maxim Cournoyer's message of "Sun, 23 Apr 2023 21:20:59 -0400")

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

Hello!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)
>
> Did you checked with Ricardo?  They were the author of that hook, per
> git blame :-).

I didn’t even look at ‘git blame’, I thought you were the one behind
this iteration :-), but Ricardo and I discussed it briefly on IRC.
Anyway, extending Cc!

>> There are probably two things to fix:
>>
>>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>>      passed to ‘union-build’.
>
> I think this is the problem to fix.  It's non-intuitive that
> manifest-lookup-package transitively looks for things instead of looking
> at the profile.  I actually got tripped by that as well when I authored
> gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
> file that reads:
>
>              ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
>              ;; every input referenced by the manifest, while MANIFEST-INPUTS
>              ;; only retrieves the immediate inputs as well as their
>              ;; propagated inputs; to avoid causing an empty output derivation
>              ;; we must ensure that the inputs contain at least one
>              ;; loaders.cache file.  This is why we include gdk-pixbuf or
>              ;; librsvg when they are transitively found.
>
> I think we need a 'manifest-lookup-inputs' or similar that stops at the
> profile, to work at the same depth as manifest-inputs.  Then it wouldn't
> find texlive-base and the hook wouldn't run (and fail).

There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
was to take whichever glib/GDK we’d find in the dependency graph, and
pick the command we need from it.  That way, we wouldn’t introduce any
additional dependency.  That was the reasoning.

Thinking about, this particular case might be easier: we can make things
consistent like so:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1443 bytes --]

diff --git a/guix/profiles.scm b/guix/profiles.scm
index 03333785f9..41f3e25bb3 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1786,6 +1786,8 @@ (define entry->texlive-input
            (cons (gexp-input thing output)
                  (append-map entry->texlive-input deps))
            '()))))
+  (define texlive-inputs
+    (append-map entry->texlive-input (manifest-entries manifest)))
   (define texlive-bin
     (module-ref (resolve-interface '(gnu packages tex)) 'texlive-bin))
   (define coreutils
@@ -1809,8 +1811,7 @@ (define build
           ;; that TeX live can resolve the parent and grandparent directories
           ;; correctly.  There might be a more elegant way to accomplish this.
           (union-build "/tmp/texlive"
-                       '#$(append-map entry->texlive-input
-                                      (manifest-entries manifest))
+                       '#$texlive-inputs
                        #:create-all-directories? #t
                        #:log-port (%make-void-port "w"))
 
@@ -1867,7 +1868,7 @@ (define build
               (install-file (string-append b "/ls-R") a))))))
 
   (mlet %store-monad ((texlive-base (manifest-lookup-package manifest "texlive-base")))
-    (if texlive-base
+    (if (and texlive-base (pair? texlive-inputs))
         (gexp->derivation "texlive-font-maps" build
                           #:substitutable? #f
                           #:local-build? #t

[-- Attachment #3: Type: text/plain, Size: 163 bytes --]


That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
graph) *and* we have texlive-* packages in the manifest.

Thoughts?

Ludo’.

  reply	other threads:[~2023-04-24 22:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-23 23:07 bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages Ludovic Courtès
2023-04-24  1:20 ` Maxim Cournoyer
2023-04-24 21:15   ` Ludovic Courtès [this message]
2023-04-25  1:41     ` Maxim Cournoyer
2023-04-30 20:51       ` Ludovic Courtès
2023-05-01 12:24         ` Maxim Cournoyer
2023-05-04 11:14           ` Ludovic Courtès

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://guix.gnu.org/

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

  git send-email \
    --in-reply-to=878reh0yo8.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=63043@debbugs.gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).