virtual/libelf allows elfutils or libelf as provider for the virtual. This makes it possible to have a complete depgraph and missing libraries: # equery f elfutils [...] /usr/lib64/libelf.so.1 # equery f dev-libs/libelf [...] /usr/lib64/libelf.so.0 So, following scenario: binhost with default provider elfutils installed, builds package, links against libelf.so.1. client installs libelf explicitly, then fetches binpkgs. The virtual is satisfied, but now libelf.so.1 is missing and only .0 exists on the client. If you test (in a chroot for example) by removing elfutils and installing libelf you'll see this: * - /usr/lib64/libelf.so.1 * used by /bin/ip (sys-apps/iproute2-4.14.1-r2) * used by /sbin/tc (sys-apps/iproute2-4.14.1-r2) ... but on a client installing from a binhost the .1 never existed, so it's not preserved, and without 'ip' starting network fails, and aaargh whyyy nooo zomg. This is a quiet failure with a complete depgraph! So no package should depend on the virtual (or rather, the virtual should come in version 0 and 1, with 0 depending on libelf and 1 on elfutils only?) (CC:ing QA as this can break things rather severely and we should not tape handgrenades to random things for fun)
Good catch! If memory serves, I think I inherited this package this way, so either this was a problem all along, or there was a soname bump to elfutils that went unnoticed. To be honest, I'm not sure how to fix this cleanly. I could patch libelf to bump the soname -> 1, add a subslot and revbump it. Can someone in QA advise?
Well, the solution depends on how much effort you want to put into it. The easiest solution would be to version the virtual by SONAME, i.e. have: virtual/libelf-1 (slot 0/1) -> libelf virtual/libelf-2 (slot 0/2) -> elfutils However, this means that the PM will want to 'upgrade' from libelf to elfutils. So practically libelf will only be used on systems where elfutils is not available. If you want to support full, clean 'choice' between the two things become harder -- you basically go ffmpeg/libav way, i.e. additional USE flag in every package that can be used to switch between the two.
(In reply to Michał Górny from comment #2) > Well, the solution depends on how much effort you want to put into it. The > easiest solution would be to version the virtual by SONAME, i.e. have: > > virtual/libelf-1 (slot 0/1) -> libelf > virtual/libelf-2 (slot 0/2) -> elfutils > > However, this means that the PM will want to 'upgrade' from libelf to > elfutils. So practically libelf will only be used on systems where elfutils > is not available. > > If you want to support full, clean 'choice' between the two things become > harder -- you basically go ffmpeg/libav way, i.e. additional USE flag in > every package that can be used to switch between the two. We actually have 3 providers of libelf.so (see libelf-1.ebuild) >=dev-libs/elfutils-0.155-r1:0/0[${MULTILIB_USEDEP}] >=sys-freebsd/freebsd-lib-9.2_rc1[${MULTILIB_USEDEP}] >=dev-libs/libelf-0.8.13-r2:0/0[${MULTILIB_USEDEP}] So I don't know what to so with freebsd-lib. I can't even build it locally because its use for profiles/default/bsd systems.
That is actually interesting. Given that freebsd-lib is obligatory on BSD, I don't understand why separate dev-libs/libelf has FBSD keywords as well...
(In reply to Michał Górny from comment #4) > That is actually interesting. Given that freebsd-lib is obligatory on BSD, I > don't understand why separate dev-libs/libelf has FBSD keywords as well... If sys-freebsd/freebsd-lib could be move to bsd's @system, then we could remove it from the virtual and I could more easily clean up. I've cc-ed the bsd folks to see if they want to weigh in.
(In reply to Anthony Basile from comment #5) > (In reply to Michał Górny from comment #4) > > That is actually interesting. Given that freebsd-lib is obligatory on BSD, I > > don't understand why separate dev-libs/libelf has FBSD keywords as well... > > If sys-freebsd/freebsd-lib could be move to bsd's @system, then we could > remove it from the virtual and I could more easily clean up. > > I've cc-ed the bsd folks to see if they want to weigh in. freebsd-lib is in system. It is in the virtual because it is a provider for the same API and as such is needed to satisfy dependencies. I think dev-libs/libelf is keyworded for before when it was possible to use it and remove the fbsd bundled one. fbsd libelf comes from here: https://sourceforge.net/p/elftoolchain/wiki/Home/ supposedly compatible with redhat's elfutils but the latter does not build on anything non-linux IIRC
I'd say: -2 w/ || ( elfutils:subslot freebsd-lib ) -1 w/ libelf:subslot, masked on fbsd
(In reply to Michał Górny from comment #7) > I'd say: > > -2 w/ || ( elfutils:subslot freebsd-lib ) > -1 w/ libelf:subslot, masked on fbsd Yeah that's what I was thinking. Can I get an ack from the bsd folks if this is an okay approach for them? I'll prepare a fix today.
(In reply to Anthony Basile from comment #8) > (In reply to Michał Górny from comment #7) > > I'd say: > > > > -2 w/ || ( elfutils:subslot freebsd-lib ) > > -1 w/ libelf:subslot, masked on fbsd > > Yeah that's what I was thinking. Can I get an ack from the bsd folks if > this is an okay approach for them? I'll prepare a fix today. err sorry for the spam. I mean I'll prepare a patch today.
(In reply to Anthony Basile from comment #8) > (In reply to Michał Górny from comment #7) > > I'd say: > > > > -2 w/ || ( elfutils:subslot freebsd-lib ) > > -1 w/ libelf:subslot, masked on fbsd if libelf is considered deprecated and no ebuild will ever depend on :1 then definitely (dont mask it though, put -*-fbsd keywords in the -1 virtual) otherwise, you can also put fbsd-lib in -1: the original soname issue is irrelevant for fbsd
(In reply to Alexis Ballier from comment #10) > (In reply to Anthony Basile from comment #8) > > (In reply to Michał Górny from comment #7) > > > I'd say: > > > > > > -2 w/ || ( elfutils:subslot freebsd-lib ) > > > -1 w/ libelf:subslot, masked on fbsd > > if libelf is considered deprecated and no ebuild will ever depend on :1 then > definitely > (dont mask it though, put -*-fbsd keywords in the -1 virtual) right now libelf is being used by musl and uclibc-ng systems. i'm not sure what the -*-fbsd keywords are, but i'll look in the tree and try to figure it out from there before i produce a patch. > > otherwise, you can also put fbsd-lib in -1: the original soname issue is > irrelevant for fbsd actually, i've got another idea. let me see if feebsd-lib works on musl and uclib-ng. if it does, we'll just drop libelf.
(In reply to Anthony Basile from comment #11) > > > > otherwise, you can also put fbsd-lib in -1: the original soname issue is > > irrelevant for fbsd > > actually, i've got another idea. let me see if feebsd-lib works on musl and > uclib-ng. if it does, we'll just drop libelf. hmm, fbsd-lib is the libc too, so I doubt it :)
I suppose you don't want to build the whole FreeBSD userspace but instead try the underlying project. However, I feel we'll be talking of three competing implementations soon enough.
Okay, I tested a simple solution of just splitting the virtuals and masking on musl and uclibc-ng and this resolves the issue. Let me know if you want anything else added/changed. In particular, I didn't mask anything on fbsd. Once the patch lands, the virtual will update to virtual-2 on glibc and fbsd systems, while nothing will change on musl and uclibc-ng systems.
Created attachment 514204 [details, diff] split virtual/libelf into two
Given that it's a major change, it either deserves a revbump or completely new version number. Also subslots should be different between the two versions.
Comment on attachment 514204 [details, diff] split virtual/libelf into two > # packages that unconditionally depend on dev-libs/elfutils > <net-firewall/fwbuilder-5.3.7 >diff --git a/virtual/libelf/libelf-1.ebuild b/virtual/libelf/libelf-1.ebuild >index b2acd4bb712..3cfc6c308b7 100644 >--- a/virtual/libelf/libelf-1.ebuild >+++ b/virtual/libelf/libelf-1.ebuild >@@ -9,9 +9,4 @@ DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" > SLOT="0/1" > KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~x86-linux ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" replace those '~' by '-' on the fbsd keywords >new file mode 100644 >index 00000000000..ab3e0afb047 >--- /dev/null >+++ b/virtual/libelf/libelf-2.ebuild >@@ -0,0 +1,16 @@ >+# Copyright 1999-2017 Gentoo Foundation >+# Distributed under the terms of the GNU General Public License v2 >+ >+EAPI=6 >+ >+inherit multilib-build >+ >+DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" >+SLOT="0/1" use a different subslot than -1 here
(In reply to Alexis Ballier from comment #17) > Comment on attachment 514204 [details, diff] [details, diff] > split virtual/libelf into two > > > # packages that unconditionally depend on dev-libs/elfutils > > <net-firewall/fwbuilder-5.3.7 > >diff --git a/virtual/libelf/libelf-1.ebuild b/virtual/libelf/libelf-1.ebuild > >index b2acd4bb712..3cfc6c308b7 100644 > >--- a/virtual/libelf/libelf-1.ebuild > >+++ b/virtual/libelf/libelf-1.ebuild > >@@ -9,9 +9,4 @@ DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" > > SLOT="0/1" > > KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~x86-linux ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" > > replace those '~' by '-' on the fbsd keywords -foo is invalid in keywords. Only -* is valid, although discouraged. > > > >new file mode 100644 > >index 00000000000..ab3e0afb047 > >--- /dev/null > >+++ b/virtual/libelf/libelf-2.ebuild > >@@ -0,0 +1,16 @@ > >+# Copyright 1999-2017 Gentoo Foundation > >+# Distributed under the terms of the GNU General Public License v2 > >+ > >+EAPI=6 > >+ > >+inherit multilib-build > >+ > >+DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" > >+SLOT="0/1" > > use a different subslot than -1 here
(In reply to Michał Górny from comment #18) > (In reply to Alexis Ballier from comment #17) > > Comment on attachment 514204 [details, diff] [details, diff] [details, diff] > > split virtual/libelf into two > > > > > # packages that unconditionally depend on dev-libs/elfutils > > > <net-firewall/fwbuilder-5.3.7 > > >diff --git a/virtual/libelf/libelf-1.ebuild b/virtual/libelf/libelf-1.ebuild > > >index b2acd4bb712..3cfc6c308b7 100644 > > >--- a/virtual/libelf/libelf-1.ebuild > > >+++ b/virtual/libelf/libelf-1.ebuild > > >@@ -9,9 +9,4 @@ DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" > > > SLOT="0/1" > > > KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~x86-linux ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" > > > > replace those '~' by '-' on the fbsd keywords > > -foo is invalid in keywords. Only -* is valid, although discouraged. wrong https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2
(In reply to Alexis Ballier from comment #19) > (In reply to Michał Górny from comment #18) > > (In reply to Alexis Ballier from comment #17) > > > Comment on attachment 514204 [details, diff] [details, diff] [details, diff] [details, diff] > > > split virtual/libelf into two > > > > > > > # packages that unconditionally depend on dev-libs/elfutils > > > > <net-firewall/fwbuilder-5.3.7 > > > >diff --git a/virtual/libelf/libelf-1.ebuild b/virtual/libelf/libelf-1.ebuild > > > >index b2acd4bb712..3cfc6c308b7 100644 > > > >--- a/virtual/libelf/libelf-1.ebuild > > > >+++ b/virtual/libelf/libelf-1.ebuild > > > >@@ -9,9 +9,4 @@ DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" > > > > SLOT="0/1" > > > > KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~x86-linux ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" > > > > > > replace those '~' by '-' on the fbsd keywords > > > > -foo is invalid in keywords. Only -* is valid, although discouraged. > > wrong > > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2 Wrong. https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-260003.1.7 It seems that the future addition you're mentioning doesn't conform to the original spec PMs implement. In any case, -keyword breaks pkgcore -> you can't use it.
(In reply to Michał Górny from comment #20) > > > -foo is invalid in keywords. Only -* is valid, although discouraged. > > > > wrong > > > > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2 > > Wrong. > > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-260003.1.7 Hm, this says: "In contexts where it makes sense to do so, a keyword name may be prefixed by a tilde or a hyphen." But I think that 7.3.2 is indeed the more specific reference, as it is specifically about the KEYWORDS variable (its parent section is 7.3 "Optional Ebuild-defined Variables"). This also agrees with the devmanual which also mentions -arch for KEYWORDS: https://devmanual.gentoo.org/keywording/index.html > In any case, -keyword breaks pkgcore -> you can't use it. Looks like a bug in pkgcore?
(In reply to Michał Górny from comment #16) > Given that it's a major change, it either deserves a revbump or completely > new version number. Also subslots should be different between the two > versions. Guys, I'm hitting a big issue with this approach. The problem is that if I split the virtual into virtual/libelf-2 (with only dev-libs/libelf) and virtual/libelf-3 (with elfutils and freebsd-lib) and then I mask >virtual/libelf-2 on musl and uclibc-ng profiles, then I get the following when virtual/libelf gets emerged. This bites me hard at stage3 catalyst. How do I make it so that it only tries to emerge virtual/libelf-2 ?? # emerge -vp virtual/libelf These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N #] dev-libs/elfutils-0.170-r1::gentoo USE="nls utils -bzip2 -lzma -static-libs {-test} (-threads)" 0 KiB [uninstall ] dev-libs/libelf-0.8.13-r2::gentoo USE="nls -debug" [blocks b ] dev-libs/elfutils ("dev-libs/elfutils" is blocking dev-libs/libelf-0.8.13-r2) [blocks b ] dev-libs/libelf ("dev-libs/libelf" is blocking dev-libs/elfutils-0.170-r1) [ebuild U #] virtual/libelf-3:0/2::gentoo [1:0/1::gentoo] 0 KiB Total: 2 packages (1 upgrade, 1 new, 1 uninstall), Size of downloads: 0 KiB Conflict: 2 blocks The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by sys-apps/iproute2-4.14.1-r2::musl[-minimal] # required by @system # required by @world (argument) # /usr/portage/profiles/default/linux/musl/package.mask: # dev-libs/elfutils needs a port to musl, bug #602126 =virtual/libelf-3 # required by virtual/libelf-3::gentoo # required by virtual/libelf (argument) # /usr/portage/profiles/default/linux/musl/package.mask: # dev-libs/elfutils needs a port to musl, bug #602126 =dev-libs/elfutils-0.170-r1 NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes.
Please try =virtual/libelf-2 and see if that changes anything.
Created attachment 514482 [details, diff] split virtual/libelf into two Okay this patch should address all issues: 1) I removed libelf-0 which is no longer needed now 2) I split the old libelf-1 into libelf-2 and libelf-3. I removed the libelf-1. 3) libelf-2 depends only on dev-libs/libelf and is slotted SLOT="0/1" 4) I dropped all *bsd* keywords from libelf-2. I left the prefix keywords and the regular keywords. 5) libelf-3 depends on both elfutils and freebsd-libs. It is slotted SLOT="0/2" 6) libelf-3 retains all the keywords form the old libelf-1. 7) >libelf-2 is masked on musl and uclibc-ng profiles ack away and I'll commit.
Comment on attachment 514482 [details, diff] split virtual/libelf into two >diff --git a/profiles/default/linux/musl/package.mask b/profiles/default/linux/musl/package.mask >index c4367eb8487..303f8b5b4ca 100644 >--- a/profiles/default/linux/musl/package.mask >+++ b/profiles/default/linux/musl/package.mask >@@ -14,6 +14,7 @@ sys-fs/udev > > # dev-libs/elfutils needs a port to musl, bug #602126 > dev-libs/elfutils >+>virtual/libelf-2 Use >=. > will accidentally match 2-r1 if that happens. >--- /dev/null >+++ b/virtual/libelf/libelf-2.ebuild >@@ -0,0 +1,12 @@ >+# Copyright 1999-2017 Gentoo Foundation >+# Distributed under the terms of the GNU General Public License v2 >+ >+EAPI=6 >+ >+inherit multilib-build >+ >+DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" Did you mean: .so.0 & dev-libs/libelf? ;-) >+SLOT="0/1" Hmm, given that majority of users have elfutils installed already, I think it'd be better to use 0/0 for libelf, and 0/1 for elfutils. >+KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~x86-linux" >+ >+RDEPEND=">=dev-libs/libelf-0.8.13-r2:0/0[${MULTILIB_USEDEP}]" >diff --git a/virtual/libelf/libelf-1.ebuild b/virtual/libelf/libelf-3.ebuild >similarity index 88% >rename from virtual/libelf/libelf-1.ebuild >rename to virtual/libelf/libelf-3.ebuild >index b2acd4bb712..7ff12f5d83d 100644 >--- a/virtual/libelf/libelf-1.ebuild >+++ b/virtual/libelf/libelf-3.ebuild >@@ -6,12 +6,11 @@ EAPI=6 > inherit multilib-build > > DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" >-SLOT="0/1" >+SLOT="0/2" > KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-linux ~arm-linux ~x86-linux ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" > > RDEPEND=" > || ( > >=dev-libs/elfutils-0.155-r1:0/0[${MULTILIB_USEDEP}] > >=sys-freebsd/freebsd-lib-9.2_rc1[${MULTILIB_USEDEP}] >- >=dev-libs/libelf-0.8.13-r2:0/0[${MULTILIB_USEDEP}] > )"
(In reply to Michał Górny from comment #25) > Comment on attachment 514482 [details, diff] [details, diff] > split virtual/libelf into two > > >diff --git a/profiles/default/linux/musl/package.mask b/profiles/default/linux/musl/package.mask > >index c4367eb8487..303f8b5b4ca 100644 > >--- a/profiles/default/linux/musl/package.mask > >+++ b/profiles/default/linux/musl/package.mask > >@@ -14,6 +14,7 @@ sys-fs/udev > > > > # dev-libs/elfutils needs a port to musl, bug #602126 > > dev-libs/elfutils > >+>virtual/libelf-2 > > Use >=. > will accidentally match 2-r1 if that happens. > > >--- /dev/null > >+++ b/virtual/libelf/libelf-2.ebuild > >@@ -0,0 +1,12 @@ > >+# Copyright 1999-2017 Gentoo Foundation > >+# Distributed under the terms of the GNU General Public License v2 > >+ > >+EAPI=6 > >+ > >+inherit multilib-build > >+ > >+DESCRIPTION="Virtual for libelf.so.1 provider (dev-libs/elfutils)" > > Did you mean: .so.0 & dev-libs/libelf? ;-) yes. > > >+SLOT="0/1" > > Hmm, given that majority of users have elfutils installed already, I think > it'd be better to use 0/0 for libelf, and 0/1 for elfutils. That's what I had and you suggested otherwise! Okay so if I go with SLOT="0/0" in libelf-2 and SLOT="0/1" in libelf-3 is the patch good to go?
I think so.
(In reply to Michał Górny from comment #27) > I think so. okay it landed. to be complete, i should add that I also had to drop ia64 from libelf-2 because dev-libs/libelf isn't keyworded on that arch. not a big deal.
