From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id C95C03858D32 for ; Sun, 22 Jan 2023 14:57:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C95C03858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=57833 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pJbmQ-006b8c-N3; Sun, 22 Jan 2023 14:57:10 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1pJbVX-0009kS-MM; Sun, 22 Jan 2023 15:39:43 +0100 From: Florian Weimer To: =?iso-8859-1?Q?Na=EFm?= Favier via Libc-stable Cc: =?iso-8859-1?Q?Na=EFm?= Favier Subject: Re: Backport Unicode updates? References: <37983ebf-6323-6dd1-de0c-0d26df2b237c@monade.li> Date: Sun, 22 Jan 2023 15:39:43 +0100 In-Reply-To: <37983ebf-6323-6dd1-de0c-0d26df2b237c@monade.li> (=?iso-8859-1?Q?=22Na=EFm?= Favier via Libc-stable"'s message of "Thu, 24 Nov 2022 11:41:28 +0100") Message-ID: <877cxeeiq8.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Na=EFm Favier via Libc-stable: > It would be nice to backport Unicode updates (and more generally > changes to locale data, I guess) to release branches, so that > distributions can include them more quickly. See > https://github.com/weechat/weechat/issues/79, > https://github.com/NixOS/nixpkgs/issues/202548 for more context. > > For example, could the Unicode 15 support in 7fe6734d28 be > backported to the stable 2.36 (and maybe 2.35) branches without > breaking anything? Changes to collation order and case conversion have broken on-disk data structures in the past (such as B-tree indices for PostgreSQL). So it's not risk-free.