Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0BNV-0002vJ-5U for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Nov 2022 00:55:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p0BNU-0001z9-34 for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Nov 2022 00:55:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0BNT-0001z0-PM for pgsql-hackers@lists.postgresql.org; Wed, 30 Nov 2022 00:55:07 +0000 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p0BNR-000182-5z for pgsql-hackers@postgresql.org; Wed, 30 Nov 2022 00:55:07 +0000 Received: by mail-ua1-x92a.google.com with SMTP id c26so5664986uak.5 for ; Tue, 29 Nov 2022 16:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O1R3Tqswk5amdeTrB0kIYLbZFNheUTC23fgPB1XCnZg=; b=EeRYMUmsrlQichQ9NaOTSTY/w96Eq+RBIRSL3G2vBjgNpINENQJDED6vty2VOzv17W OKxInfSip/W2hFFA894KPVWllsLGAphTT/sk+RDymm59NnocpwQjLoSE3ImB3qX1zcAl DMBeTXJxRSckS0/u0vywepEVzaIxnhPVCyTdiKhb77NbGHcGtQsoA753y9R3LLwTTGA+ fm6RXO6ayyUITUB5suPW6iLamGeV+UZHBOSbnV09YiSBL00F+EttDwqWcif6M//nMYU/ L4yvY8MJiciBS1BQv/RFUgtMWADvDIopFvV6Me5ldwHSvQN2HZR+5ZGA55IjPV6mm1V0 Ewbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O1R3Tqswk5amdeTrB0kIYLbZFNheUTC23fgPB1XCnZg=; b=4Q/qhd6ZgMgvxVosI1WYvmHoa+sAJOBAav+9YgWfRDbG1xe97DYcllgPdq9RCVzxaH cDjKhXTVN5DR9d3Y4wI5LCxh6fqtQwmqRRPu3YwnWeKgTvEYrkRdrdnXrO5eTajT260C zJlFyU7MmBmHMp+K4lyp5ZJP6y21vp/JCEWWAIMAjd3cblXaNpoeA9z7Mlet5HIw8Spj Bop0zWuJJowO3zmWzA/ml9uFvXZIO4YjXCbcM4Y2aksS7EaM8E47OW90EGFJqwcK6BHE 48X+595hd5g9y3NkkQUTiNtc9Fb7+/5YZ4NgrbY01e0gLZ5E698r59C7dObi1JgkeeKH jFfg== X-Gm-Message-State: ANoB5pkAvARiso5xw16DVKo2h0/h35QxHbdm3FOXHg4ZBotok53Q2wPs 52mOVUYTY4hZFz7JAgM8sokDoI32ZYRX4uowuyU= X-Google-Smtp-Source: AA0mqf7Fxab1EeQFD8uhJI5hJwNykJ3LKgoycTshV/wJ0ORjQ9seXiE5W/IH8aO+SyRT5nsBFx7xgUFjFmC+DGotS5I= X-Received: by 2002:ab0:6647:0:b0:419:890:9c08 with SMTP id b7-20020ab06647000000b0041908909c08mr14299739uaq.49.1669769702919; Tue, 29 Nov 2022 16:55:02 -0800 (PST) MIME-Version: 1.0 References: <398aabd1-ad95-ba2d-d70a-dd5d90bf6e07@enterprisedb.com> <606bd2baa6d65b38fee6eb23bba40c5da210255b.camel@j-davis.com> <9f8e9b5a3352478d4cf7d6c0a5dd7e82496be4b6.camel@j-davis.com> <83faecb4a89dfb5794938e7b4d9f89daf4c5d631.camel@j-davis.com> <6fec1a3a681623941c514e9ae0d97f42af417209.camel@j-davis.com> In-Reply-To: <6fec1a3a681623941c514e9ae0d97f42af417209.camel@j-davis.com> From: Thomas Munro Date: Wed, 30 Nov 2022 13:54:26 +1300 Message-ID: Subject: Re: Collation version tracking for macOS To: Jeff Davis Cc: Robert Haas , Peter Eisentraut , Jeremy Schneider , Peter Geoghegan , "Finnerty, Jim" , "Nasby, Jim" , Tom Lane , pgsql-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 30, 2022 at 1:25 PM Jeff Davis wrote: > On Wed, 2022-11-30 at 10:52 +1300, Thomas Munro wrote: > > On Wed, Nov 30, 2022 at 8:38 AM Jeff Davis wrote: > > > On Tue, 2022-11-29 at 10:46 -0800, Jeff Davis wrote: > > > https://unicode-org.atlassian.net/browse/ICU-22216 > > > > I'm no expert on loader/linker arcana but I have a feeling this is a > > dead end. It's an ancient Unix or at least elf-era Unix convention > > that SONAMEs have major versions only, because major versions are the > > basis of ABI stability. > > It's possible that it's more a problem of how they are doing it: the > specific version is coming from a dependency rather than the library > itself. The results are surprising, so I figured it's worth a report. > Let's see what they say. > > Regardless, even if they did make a change, it's not going to help us > anytime soon. We can't rely on any scheme that involves multiple minor > versions for a single major version being installed at once. That means > that, if you create a collation depending on ICU X.Y, and then it gets > upgraded to X.(Y+1), and you create another collation depending on that > library version, you are stuck. Mainstream package maintainers aren't going to let that happen anyway as discussed, so this would always be a fairly specialised concern. Maybe someone in our community would be motivated to publish a repo full of mutant packages that don't conflict with each other and that have specially modified DT_NEEDED, or are rolled into one single library so the DT_NEEDED problem goes away.