GNU bug report logs -
#42164
Combining file-append with gexps results in incomprehensible errors
Previous Next
Full log
View this message in rfc822 format
Hi Jakub!
Jakub Kądziołka <kuba <at> kadziolka.net> writes:
> Consider this minimal operating-system definition:
>
> (use-modules (gnu))
> (use-package-modules gcc)
>
> (operating-system
> (host-name "test")
> (timezone "UTC")
> (bootloader (bootloader-configuration
> (bootloader grub-efi-bootloader)
> (target "/boot/efi")))
> (file-systems (cons*
> (file-system
> (device (file-system-label "root"))
> (mount-point "/")
> (type "ext4"))
> %base-file-systems))
> (packages '())
> (services (cons*
> (service special-files-service-type
> `(("/lib64" ,(directory-union "rustup-libs"
> (list
> (file-append glibc "/lib")
> (file-append #~#$gcc:lib "/lib"))))))
> %base-services)))
>
> I would expect this way of specifying a specific output of a package to
> work, but it results in the following error:
>
> ice-9/boot-9.scm:1515:18: object is not an exception of the right type #<&gexp-input-error input: #<gexp #<gexp-input #<package gcc <at> 7.5.0 gnu/packages/gcc.scm:520 7f06c996c960>:lib> 7f06c6b06990>> #<record-type &package-input-error>
[...]
> I have figured out that the following does work:
>
> (service special-files-service-type
> `(("/lib64" ,#~(directory-union "rustup-libs"
> (list
> (string-append #$glibc "/lib")
> (string-append #$gcc:lib "/lib"))))))
>
> However, I would expect the other variants to work as well. The
> documentation and error messages are lacking in this regard.
This seems to come up every time I have to specify a non-default package
output; I've investigated the issue a bit and it seems to be caused by
the lack of a gexp-compiler for the gexp object resulting from
#$package:output, which is of type gexp-input as represented by, for
example:
#<gexp-input #<package opendht <at> 2.2.0rc4 /home/maxim/src/guix/gnu/packages/networking.scm:3426 7f2dbcae1aa0>:tools>
From the REPL
(lower-object (gexp (ungexp opendht "tools")))
$17 = #<procedure 7f2db56ed100 at guix/gexp.scm:246:2 (state)>
scheme@(gnu services jami)> ,run-in-store $17
While executing meta-command:
ERROR:
1. &gexp-input-error: #<gexp #<gexp-input #<package opendht <at> 2.2.0rc4
/home/maxim/src/guix/gnu/packages/networking.scm:3426
7f2dbcae1aa0>:tools> 7f2db7427690>
So if we were to define/register a gexp-compiler for this kind of
gexp-input, we could make it work, but I haven't yet investigated how
easy/difficult that would be.
Seems worthwhile though, this issue is quite annoying when attempting to
work with specific outputs!
Thanks for the detailed report.
Maxim
This bug report was last modified 3 years and 30 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.