Hi, Mark H Weaver <[email protected]> writes:
> Ugh. I'd prefer to avoid removing 'gtk+' from the inputs to 'emacs' on > any system, because the distinguishing characteristic of that package > (compared with the other Emacs variants) is that it's the Gtk+ variant > of Emacs. How about a patch like the following - would it be acceptable to you?
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 98061c93ae..4d2caf205a 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -71,6 +71,7 @@
#:use-module (gnu packages xml)
#:use-module (gnu packages xorg)
#:use-module (guix utils)
+ #:use-module (ice-9 match)
#:use-module (srfi srfi-1))
(define-public emacs
@@ -236,7 +237,12 @@
("libpng" ,libpng)
("zlib" ,zlib)
- ("librsvg" ,librsvg)
+ ;; librsvg is an optional dependency that pulls in rust. Rust is not
+ ;; supported well on every architecture yet.
+ ,@(match (or (%current-target-system)
+ (%current-system))
+ ("x86_64-linux" `(("librsvg" ,librsvg)))
+ (_ '()))
("libxpm" ,libxpm)
("libxml2" ,libxml2)
("libice" ,libice)
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index f458366fb6..0468cbf830 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -776,7 +776,12 @@ is part of the GNOME accessibility project.")
(outputs '("out" "bin" "doc"))
(propagated-inputs
`(("atk" ,atk)
- ("gdk-pixbuf" ,gdk-pixbuf+svg)
+ ;; SVG support is optional and requires librsvg, which pulls in rust.
+ ;; Rust is not supported well on every architecture yet.
+ ("gdk-pixbuf" ,(match (or (%current-target-system)
+ (%current-system))
+ ("x86_64-linux" gdk-pixbuf+svg)
+ (_ gdk-pixbuf)))
("pango" ,pango)))
(inputs
`(("cups" ,cups)
@@ -843,7 +848,12 @@ application suites.")
(propagated-inputs
`(("at-spi2-atk" ,at-spi2-atk)
("atk" ,atk)
- ("gdk-pixbuf" ,gdk-pixbuf+svg)
+ ;; SVG support is optional and requires librsvg, which pulls in rust.
+ ;; Rust is not supported well on every architecture yet.
+ ("gdk-pixbuf" ,(match (or (%current-target-system)
+ (%current-system))
+ ("x86_64-linux" gdk-pixbuf+svg)
+ (_ gdk-pixbuf)))
("libepoxy" ,libepoxy)
("libxcursor" ,libxcursor)
("libxi" ,libxi)
I've tested this patch (on its own, applied to wip-ppc64le locally, without the other two patches mentioned earlier in this thread), and it successfully restores the "supported systems" for emacs (thus fixing the tests/package.sh test failure), without changing rust's list of supported systems, which remains hard-coded to x86_64-linux. Eventually I think I will definitely need a change like the one Chris proposed in order to actually troubleshoot build failures involving rust on powerpc64le-linux, but I suppose when the time comes, I can do it in a private branch and save the build farm some wasted cycles. It's fine with me if we don't make a change like that right now, since it isn't blocking my porting work. Mark H Weaver <[email protected]> writes: > Aside: I wish that Guix included a convenient tool to answer the > question "Why does package X depend on package Y?", i.e. "What paths of > dependencies lead from package X to package Y?", without having to view > the entire dependency graph (which is often too complex to grasp > visually). Ricardo Wurmus <[email protected]> writes: > (“guix graph” is of no help here, because it doesn’t show build system > packages, so I looked through the derivations.) The "--paths" option with "--type=bag" shows you this (results below were, of course, taken before applying the patch above): --8<---------------cut here---------------start------------->8--- marusich@suzaku:~/repos/guix$ ./pre-inst-env guix graph --type=bag --path gtk+ rust [email protected] [email protected] [email protected] [email protected] --8<---------------cut here---------------end--------------->8--- Christopher Baines <[email protected]> writes: > I've gone ahead and pushed the patch I proposed to master, I think it's > a step forward. > > As you say, adapting the change for core-updates might be good as > well. I want to check though if rust builds for i686-linux on > core-updates, as the path is different to master, so it may well work. > > So yeah, once I've found out whether rust works on i686-linux on > core-updates, I might make a change there too. I don't have a strong personal opinion about this, since I'm building everything from source anyway, and I want a patch like this eventually on core-updates, too. However, in light of Mark's comments, is it a good idea to apply that patch right now? -- Chris
signature.asc
Description: PGP signature
