Both of these patches fix the issue for me. After applying either one
in isolation (on the wip-ppc64le branch, which was recently rebased onto
core-updates), the list of supported systems for the emacs package
correctly includes other systems, including powerpc64le-linux, and thus
the tests/guix-package.sh test passes on my powerpc64le-linux system.
I think both of these patches are important and needed. The patch to
restore supported systems to the rust package is important because we
will want rust to build successfully on many systems. The patch to only
add gtk+ and librsvg inputs to emacs when the system is x86_64-linux is
important because it would be advantageous to be able to use emacs
without depending on rust on systems like powerpc64le-linux, where Rust
support may not be great yet.
It's also convenient for me, personally, because I don't really want to
deal with Rust right now just to get Emacs working on powerpc64le-linux.
Once I can build a Guix release binary for powerpc64le-linux, then I
think I can start worrying more about Rust. I have taken the liberty of
applying these patches to the wip-ppc64le branch as-is, since they work
for me. I can remove them later if we don't like it.
We will undoubtedly run into a similar situation with other packages
going forward, like Mark mentioned. Debian ran into this very issue
some time ago, and apparently it caused a bit of consternation:
Apparently, powerpc64le-unknown-linux-gnu is a "Tier 2" Rust platform,
which I guess means it's pretty well supported, but not as well as "Tier
1". I hope that we can get it all working, since librsvg is depended
upon in some way or another by about 2700 packages (about 17% of the
total Guix package collection). In the meantime, limiting the blast
radius as needed, like Mark suggested, seems like the right thing to do
until Rust support improves on other architectures.