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.
rust without MULTILIB_USEDEP isn't really going to fly here, as it breaks amd64 multilib build consistency
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.
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.
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.
you mean https://bugs.gentoo.org/747760 ?
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.
The bug has been referenced in the following commit(s):
Author: David Michael <firstname.lastname@example.org>
AuthorDate: 2020-12-08 23:06:13 +0000
Commit: Matt Turner <email@example.com>
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: https://bugs.gentoo.org/723112
Package-Manager: Portage-3.0.9, Repoman-3.0.2
Signed-off-by: David Michael <firstname.lastname@example.org>
Signed-off-by: Matt Turner <email@example.com>
gnome-base/librsvg/librsvg-2.40.21.ebuild | 49 +++++++++++++++----------------
1 file changed, 23 insertions(+), 26 deletions(-)