From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Carlos O'Donell <carlos@redhat.com>,
Florian Weimer <fweimer@redhat.com>,
libc-alpha@sourceware.org
Subject: Re: [PATCH 0/4] Do not install shared objects under versioned names
Date: Mon, 28 Jun 2021 09:12:40 +0530 [thread overview]
Message-ID: <51ae487c-eff5-1990-189c-920a21bebe4e@gotplt.org> (raw)
In-Reply-To: <f8630246-f413-b335-38a1-35d2ffb65ecd@redhat.com>
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
next prev parent reply other threads:[~2021-06-28 3:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 8:22 Florian Weimer
2021-06-10 8:23 ` [PATCH 1/4] nptl_db: Install libthread_db under a regular implementation name Florian Weimer
2021-06-27 21:32 ` Carlos O'Donell
2021-06-10 8:23 ` [PATCH 2/4] Makerules: Remove lib-version, $(subdir-version) Florian Weimer
2021-06-27 21:32 ` Carlos O'Donell
2021-06-10 8:23 ` [PATCH 3/4] elf: Generalize name-based DSO recognition in ldconfig Florian Weimer
2021-06-27 21:32 ` Carlos O'Donell
2021-06-10 8:23 ` [PATCH 4/4] Install shared objects under their ABI names Florian Weimer
2021-06-27 21:32 ` Carlos O'Donell
2021-06-14 11:04 ` [PATCH 0/4] Do not install shared objects under versioned names Florian Weimer
2021-06-14 14:49 ` Siddhesh Poyarekar
2021-06-27 20:43 ` Carlos O'Donell
2021-06-28 3:42 ` Siddhesh Poyarekar [this message]
2021-06-27 21:31 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51ae487c-eff5-1990-189c-920a21bebe4e@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).