Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 753764 - gnome-base/librsvg: EAPI 7 request
Summary: gnome-base/librsvg: EAPI 7 request
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
Keywords: EBUILD, PullRequest
Depends on:
Reported: 2020-11-09 19:06 UTC by David Michael
Modified: 2020-12-18 22:05 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

EAPI 7 update (librsvg-2.48.9-r1.ebuild,2.56 KB, text/plain)
2020-11-09 19:06 UTC, David Michael

Note You need to log in before you can comment on or make changes to this bug.
Description David Michael 2020-11-09 19:06:35 UTC
Created attachment 670643 [details]
EAPI 7 update

Attached is an EAPI 7 ebuild.  This fixes cross-compiling EAPI 6 multilib dependencies and puts native tools in BDEPEND.  The resulting binpkg contains the same files as the EAPI 6 version for all USE flag combinations.

When switching to gnome2-utils.eclass, I only used the gdk-pixbuf loader postscripts since that's the only eclass-handled stuff that gets installed by the package.

Note that Rust is in BDEPEND now, so it had to drop its multilib USE dependencies due to bug #723112.  It just has to expect that the user built Rust with appropriate targets enabled.
Comment 1 Mart Raudsepp gentoo-dev 2020-11-09 21:05:02 UTC
rust without MULTILIB_USEDEP isn't really going to fly here, as it breaks amd64 multilib build consistency
Comment 2 David Michael 2020-11-09 21:18:18 UTC
It won't be possible to cross-compile librsvg if it uses MULTILIB_USEDEP.  If that is a real requirement, can the 2.40 ebuild be updated to EAPI 7 so the versions with broken dependencies can be masked?

Rust really shouldn't be using multilib anyway.  CHOST triplets do not map to Rust targets sensibly.  Rust has different builtin targets for what is otherwise handled by CPU_FLAGS settings, so the Rust targets built for multilib ABIs are inappropriate or don't work half the time as is.
Comment 3 Mart Raudsepp gentoo-dev 2020-11-10 20:45:09 UTC
You can discuss this with the rust maintainers, I guess. Building multilib is the main use case, and it'll just fail build with rust-bin if it's not enabled.
I'm not sure why this is affecting anything cross for you, as those flags shouldn't really be in effect there.
Comment 4 David Michael 2020-11-10 22:20:43 UTC
The multilib flags on virtual/rust in BDEPEND in the EAPI 7 affect me as is explained in bug #723112 comment #0.  I'll CC the Rust list, because this is going to prevent any multilib Rust package from using EAPI 7.

The multilib flags on everything else in DEPEND in the current EAPI 6 version affect me because I had to drop --root-deps=rdeps due to it causing other bugs, so those USE flags are enforced in BROOT until the packages upgrade to EAPI 7.  This breaks everything for the same reason as bug #723112.

My previous comment now looks like I was mashing multiple complaints together, so I'll try to clarify.  This is related more to Rust maintenance than librsvg...

Rust target triplets do not map to CHOST triplets, because different Rust targets can include what is covered by CPU_FLAGS for the same CHOST.

  - For example, Gentoo builds Rust's i686-unknown-linux-gnu target for the x86 ABI, which requires SSE2.  That would be fine for most i686 chips, but I have a Geode CPU (embedded i686 with no SSE), so I need to build the i586-unknown-linux-gnu target with my i686 CHOST.

  - Another example, Gentoo builds the armv7-unknown-linux-gnueabihf target for armv7a CHOSTs.  Rust has a different target thumbv7neon-unknown-linux-gnueabihf to include NEON and Thumb, which is automatically required by the Firefox build system when CPU_FLAGS has neon, so Firefox won't build without the additional target.

So I think dev-lang/rust should be handled more like GCC, where it can be installed with whatever arbitrary set of targets without having its own multilib ABI USE flags.  Packages could use an environment variable RUST_TARGET in make.conf (with a default from each arch profile) to pick which target to use, allowing the equivalent of setting CPU_FLAGS and CHOST.  Multilib packages could use a variant for each ABI e.g. RUST_TARGET_x86 like CHOST_x86.
Comment 5 Georgy Yakovlev gentoo-dev 2020-11-11 00:01:15 UTC
you mean ?

problem is that for arbitrary number of arbitrary targets you need cross-toolchains available, and it's illegal to depend on cross-* in normal ebuilds.

also, current librsvg state is kinda a hack, until they make it a proper crate (work in progress).

cargo cross support is coming, multilib in pure-cargo ebuilds is a bit of a hack as well, I'll look at doing it properly with multibuild functions.

after rust_targets happen, we can also map targets to abi flags if needed.
or write dep generator function.

this is a LOT of work, I could use some help there, but it has to be ::gentoo legal way of doing things.
Comment 6 Larry the Git Cow gentoo-dev 2020-12-18 22:05:31 UTC
The bug has been referenced in the following commit(s):

commit 0b1cbe7008e00ce004e67ab455ff52902c614934
Author:     David Michael <>
AuthorDate: 2020-12-08 23:06:13 +0000
Commit:     Matt Turner <>
CommitDate: 2020-12-18 22:00:05 +0000

    gnome-base/librsvg: bump the C version to EAPI 7
    Only the old pure C version of librsvg can currently be updated
    beyond EAPI 6 due to this blocker:
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: David Michael <>
    Signed-off-by: Matt Turner <>

 gnome-base/librsvg/librsvg-2.40.21.ebuild | 49 +++++++++++++++----------------
 1 file changed, 23 insertions(+), 26 deletions(-)