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

[Carlos O'Donell]

On 6/14/21 10:49 AM, Siddhesh Poyarekar wrote:
> On 6/10/21 1:52 PM, Florian Weimer via Libc-alpha wrote:
>> This is essentially a repost of the “Add
>> --disable-major-minor-libraries configure option” series.  Joseph
>> suggested that the configure option is not needed, so this version
>> implements the change unconditionally.
>> 
>> Tested on i686-linux-gnu and x86_64-linux-gnu.  I compared two 
>> build-many-glibcs.py trees with and without these patches, using
>> this command to see if there are missing files besides the
>> versioned DSOs or any dangling symbolic links.
>> 
>> cd /home/bmg/install/glibcs && find -printf '%P\n' \ | while read x
>> ; do test -r /home/bmg-install-glibcs/$x || echo $x done \ | grep
>> -v '\-2\.33\.9000\.so$' | grep -v '/libthread_db-1\.0\.so$'
>> 
>> /home/bmg/install/glibcs is the unpatched build, 
>> /home/bmg-install-glibcs is the build with the patches applied.
>> As expected, there was no output.
> 
> I was hoping that we would go in the opposite direction with this,
> i.e. encode a unique identifier in the names of the DSOs so that they
> can be installed in parallel, maybe with configuration options to
> pass the version string, similar to the kernel.  This could for
> example allow us to implement recovery from broken glibcs without
> having to reach out for a rescue disk.

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.
 
> However I understand that it would be quite a pain to implement and
> it doesn't seem to be on anyone's TODO list, certainly not mine.  So
> I won't get in the way of this since it solves present day issues
> with library updates.  It would be interesting to hear from other
> distribution maintainers on what they think of the change.

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.

-- 
Cheers,
Carlos.