[PATCH 0/4] Do not install shared objects under versioned names

[Siddhesh Poyarekar]

On 6/28/21 2:13 AM, Carlos O'Donell wrote:
> I think this is never going to happen. I'll tell you why. At one point I
> thought it *would* happen, and I thought we needed it, but two things
> prevent it:
> 
> - Downstream QE teams rightly argue that changing libc has significant
>    impact that much of the higher level stack testing needs to be redone.
>    Consider the recent spat of seccomp/glibc, firefox/glibc, chrome/glibc
>    issues all around "internal" implementation details that touch against
>    the sandboxing.
> 
> - Containers. In the past we might have said "Yeah, we need 2 libcs for
>    the sake of two distinct requirements." Today we just run processes in
>    containers. The general concept of "multiple libraries" I think is
>    going to disappear underneath the improving container tooling. Rather
>    than 2 libcs installed, we'll have two assembled containers, each with
>    a different libc.

I'm much less concerned about multiple system glibc versions being use 
in tandem; that may even be harmful.  My concern is recovery.  I agree 
that in practice recovery is much less of a common problem; I've managed 
to brick Fedora glibc only once (ok maybe twice) in my lifetime.  So 
maybe I'm overthinking it.

> I think Florian is moving this in the *right* direction e.g. simple,
> robust, one file. Without a more compelling use case for multiple
> libcs in one setup I think this is the right move.

I agree that if there's no way to usefully utilize the version numbers 
then it's a step forward to drop them.

Siddhesh