We should inject >=${LIBC_PROVIDER}-${VERSION_OF_LIBC_PROVIDER} into RDEPEND, at the very least for binpkgs. There's a few examples of why in bug 753500 and its dupes, but the gist is that glibc at least uses symbol versioning where using a binpkg linked against a newer glibc won't work if an older glibc is installed. It's not really clear if downgrading musl works and even if it is supported, I'm not really sure it's a supported case at all.
Just want to point out a flaw with this idea: Many packages do not link with libc, which makes this RDEPEND entry pointless for them.
Have you considered how this will interact with emerge --changed-deps?
(In reply to Mike Gilbert from comment #1) > Just want to point out a flaw with this idea: > > Many packages do not link with libc, which makes this RDEPEND entry > pointless for them. Yeah, I note that in the comments in my latest push. We can use NEEDED as a proxy to be good enough, I just need to figure out the best way to pipe the information through. (In reply to Zac Medico from comment #2) > Have you considered how this will interact with emerge --changed-deps? Not yet, what do you have in mind?
> (In reply to Zac Medico from comment #2) > > Have you considered how this will interact with emerge --changed-deps? > > Not yet, what do you have in mind? Ah, the mismatch between vdb & ebuilds meaning you always get a rebuild with --changed-deps after installing one of these. Yeah, this makes me think about going back to my original plan of only doing this for binpkgs (and just injecting it into the archive). That might have a different problem wrt binpkg-changed-deps but hopefully can suppress that somehow.
(In reply to Sam James from comment #3) > (In reply to Zac Medico from comment #2) > > Have you considered how this will interact with emerge --changed-deps? > > Not yet, what do you have in mind? Something like the strip_slots function can be used to strip the libc dependency before comparison. You might apply this function to dependencies of both packages, for symmetry, just like we do with strip_slots.
*** Bug 913956 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=af550b8b5cb91f27b26d6800c3b4cdd2d86a46e6 commit af550b8b5cb91f27b26d6800c3b4cdd2d86a46e6 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-04 15:38:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-10 22:01:48 +0000 ebuild: inject implicit libc RDEPEND Inject >=${LIBC_PROVIDER}-${VERSION_OF_LIBC_PROVIDER} into RDEPEND. We already try to upgrade the virtual/libc provider and its deps aggressively but that's not so helpful if there's a binpkg for, say, one of its deps available built against a newer glibc - which ends up breaking the system because our glibc isn't new enough (symbol versioning). This is a long-standing problem for binpkg users and one of the last showstoppers for being able to use them reliably. Note that this applies to source installs too, although it matters less there; it'll make downgrading libc a bit harder for people who want to do that, but users are already prevented from doing that (pkg_* check) for glibc, and I don't really see it as a bad thing to effectively propagate this to other libcs. To fully solve the problem, we should arguably do at least one of the following: 1) Implicit >= on anything (not just libc) which installs ELF (at least a PROVIDES); 2) Implement the suggestion in bug #753500 based on analysis of used versioned symbols (*). But libc is really the critical one and the one where things explode pretty badly, especially combined with us trying to Do The Right Thing for non-binpkg cases (aggressively upgrading libc before anything else). The other cases don't matter so much as they get upgraded later and by that point, the library is usually done. (It's not really clear if downgrading musl works and even if it is supported, I'm not really sure it's a supported case at all, so I'm not bothering to carve out an exception here. It'd make this far less elegant and I don't see any benefit to doing so.) (*) util-linux is one of the examples I have in mind here as justification for either point. Bug: https://bugs.gentoo.org/753500 Bug: https://bugs.gentoo.org/913628 Signed-off-by: Sam James <sam@gentoo.org> lib/_emerge/actions.py | 7 +- lib/_emerge/depgraph.py | 22 + lib/portage/dep/__init__.py | 23 +- lib/portage/dep/libc.py | 83 ++++ lib/portage/dep/meson.build | 1 + lib/portage/package/ebuild/doebuild.py | 56 ++- lib/portage/tests/dep/meson.build | 1 + lib/portage/tests/dep/test_libc.py | 81 ++++ lib/portage/tests/emerge/meson.build | 1 + lib/portage/tests/emerge/test_actions.py | 23 +- lib/portage/tests/emerge/test_libc_dep_inject.py | 551 +++++++++++++++++++++++ 11 files changed, 831 insertions(+), 18 deletions(-) https://gitweb.gentoo.org/proj/portage.git/commit/?id=3b975f9b28d1aa6e40c93431086669ad23f6f460 commit 3b975f9b28d1aa6e40c93431086669ad23f6f460 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-04 15:37:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-10 22:01:48 +0000 ebuild: refactor flushing vdb keys Refactor how we flush these VDB keys in build-info/ to make it easier to implement bug #913628: it was a pain with the forced-append of a newline even if we might tamper with the contents later on, so just postpone flushing to disk until the end. It saves some repetition too, so double win. Bug: https://bugs.gentoo.org/913628 Signed-off-by: Sam James <sam@gentoo.org> lib/portage/package/ebuild/doebuild.py | 42 ++++++++++++++-------------------- 1 file changed, 17 insertions(+), 25 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0d365d80099d206e49b592abb30030642f8f09f9 commit 0d365d80099d206e49b592abb30030642f8f09f9 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-10 22:34:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-10 22:34:52 +0000 sys-apps/portage: add 3.0.57 Closes: https://bugs.gentoo.org/918929 Closes: https://bugs.gentoo.org/913628 Closes: https://bugs.gentoo.org/915474 Closes: https://bugs.gentoo.org/918597 Closes: https://bugs.gentoo.org/919072 Closes: https://bugs.gentoo.org/919105 Closes: https://bugs.gentoo.org/919174 Closes: https://bugs.gentoo.org/919311 Closes: https://bugs.gentoo.org/919419 Closes: https://bugs.gentoo.org/919668 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.57.ebuild | 242 +++++++++++++++++++++++++++++++++ 2 files changed, 243 insertions(+)
In the future, if we don't want to do (1) suggested in https://bugs.gentoo.org/913628#c7, we may want to allow the user to specify a list of packages to do it for, or do it for @system. But let's not worry for now - this should be good enough.
