From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 1DFA13858C3B for ; Sun, 27 Jun 2021 20:43:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1DFA13858C3B Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-526-089mhlE0MeCq9G4HsLXc2A-1; Sun, 27 Jun 2021 16:43:13 -0400 X-MC-Unique: 089mhlE0MeCq9G4HsLXc2A-1 Received: by mail-qk1-f197.google.com with SMTP id n195-20020a3740cc0000b02903b2ccb7bbe6so15829811qka.20 for ; Sun, 27 Jun 2021 13:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=O90SzjKFSvvECMgzZPzLMDtSPrjgnuEh/r8oOAUAXfo=; b=EceY/vJ+zFQ/HMTZrP+aJdiKxyIesKhke2eaz2xatYMmifjeuS844rs/VuW12vCPVw YAThm5/+7pr2oRIf0W8Yc0eZLlbn+siiXjbzDpVFOkJnjTRcMWTY+5KUddAYAUjOqLvx ramCfLg1E8HcQcwvWpgW3wc53ESY0cB016CcVATPdeF8iyoqASJLB5ISAFzlobQK2yS9 h0JB953AQVn1IGMU7E/VU7YHslVssJ3TGjheKHA/fyw6dr4Hz3A1eQkMtmGQHomGL0GL HArufthC1P7bSyuNA9suf0KitQbiY4ia75kfmN3W78cKW1ogFu5aqvDDU+DcBF8k/zO8 4R0Q== X-Gm-Message-State: AOAM533aBWPioNFJczqxXOzPGozv/2TJJXutwCH5Fi3cQu/AvzPPvWiJ EyokuZqaenAdjuIA5P0/QVaHnixalvU6ysrXtTrrnlEqkXjutVXzkdTkKVp7T7/BZG4Nn9fRT+8 tOPErpa45W5jlNKl6SziOlG/1uN85u/yfFx02+hHBnRUGX0sWQNs8B7BvXJzdbCL2xA0FaA== X-Received: by 2002:a0c:80c1:: with SMTP id 59mr22502268qvb.31.1624826592951; Sun, 27 Jun 2021 13:43:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/uyUl99J8gPedFI+qhCzRjBhMwZ73665XiVZJKOQ02EpIPp0o+f8oD7Cqitcik7/PZbdfCg== X-Received: by 2002:a0c:80c1:: with SMTP id 59mr22502255qvb.31.1624826592714; Sun, 27 Jun 2021 13:43:12 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id k124sm9040487qkc.132.2021.06.27.13.43.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Jun 2021 13:43:12 -0700 (PDT) Subject: Re: [PATCH 0/4] Do not install shared objects under versioned names To: Siddhesh Poyarekar , Florian Weimer , libc-alpha@sourceware.org References: From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Sun, 27 Jun 2021 16:43:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 20:43:17 -0000 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.