Bug 753500 – sys-apps/portage: support dynamic symbol version dependencies (like for glibc magic compat symbols)

• Status: CONFIRMED
• Product: Portage Development

[Description Zac Medico 2020-11-07 18:25:34 UTC]

Since a binary package will not work unless the required versions of glibc magic compat symbols are available, it would be nice to track these as dynamic symbol version dependencies in a way similar to how we already track soname dependencies.

[Comment 1 Mike Gilbert 2021-07-15 18:31:16 UTC]

*** Bug 802303 has been marked as a duplicate of this bug. ***

[Comment 2 Sergei Trofimovich (RETIRED) 2021-07-27 22:54:38 UTC]

Is glibc's symbol versioning special here? Any symbol addition into the library should have similar semantics.

[Comment 3 Sam James 2021-09-27 01:39:34 UTC]

*** Bug 636914 has been marked as a duplicate of this bug. ***

[Comment 4 Sam James 2022-01-16 01:57:57 UTC]

A hack would be to just force implicit >= deps on glibc at least (where elibc_glibc) as glibc is the main one that's fatal here for new versions.

[Comment 5 Zac Medico 2022-01-16 02:21:39 UTC]

(In reply to Sam James from comment #4)
> A hack would be to just force implicit >= deps on glibc at least (where
> elibc_glibc) as glibc is the main one that's fatal here for new versions.

We have a hack in emerge that makes it try to install virtual/os-headers and virtual/libc at the earliest opportunity.

[Comment 6 John Helmert III 2022-01-16 19:35:50 UTC]

(In reply to Zac Medico from comment #5)
> (In reply to Sam James from comment #4)
> > A hack would be to just force implicit >= deps on glibc at least (where
> > elibc_glibc) as glibc is the main one that's fatal here for new versions.
> 
> We have a hack in emerge that makes it try to install virtual/os-headers and
> virtual/libc at the earliest opportunity.

If I understand correctly, that solves the ordering problem, but wouldn't solve the problem of a stable system trying to use binary packages that need unstable glibc.