From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EFF2A1F47C for ; Thu, 26 Jan 2023 14:43:20 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.a=rsa-sha256 header.s=strato-dkim-0002 header.b=LK8JpRI1; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pL3T4-0004yE-1A; Thu, 26 Jan 2023 09:43:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pL3T1-0004xt-UL for bug-gnulib@gnu.org; Thu, 26 Jan 2023 09:43:07 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.219]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pL3Sz-0002Jy-Ga for bug-gnulib@gnu.org; Thu, 26 Jan 2023 09:43:07 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1674744181; cv=none; d=strato.com; s=strato-dkim-0002; b=XfUV2S9F5BJFK/4+HuhuyBFyMY1hzrzM4YP5JSH2HebN9Y11HTRzQMikf/RgmwWTQ9 WdXX5JbkCsiJ9P8EBzCOQsCQ1da8pQOAXxNaIIEb2/42FC4cq/uKHxhO+B6XG62wsZlJ If9LrH+1eQTwVsh7J/SM673j+FmS1w1c6fjTOs7ZdLYySmNr7MibiANoU13Qu25TfkG0 xtfETXvTAozgX+ao7dZL5ec4hy5GmkPTWxXcJ+5n5mHvv94UArAKymPdUTGem6amEUFL fi4VW2Um3SVyoGMNTybGuwJoNn6nZ6rZkxPG105/p0kH1w+BReTvHA3Nm3to7F1uikjE LR1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1674744181; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=U7H+frkBfMS/QfDNx+miiTVXsRSG0C5dzwZ0xkJdXnA=; b=oToEHI4vbZFW9u4WCI8UivVvobj9/w+Ixn5JULi+nKy1twz9hI8qyBmIVSZ7p1IE89 AAhWlE6VUywlobNvf6a/ilxVq2R0d5tswRmyLjXZj5+OOjK2NyDARUMTzknrYv/FnFbC 5VuPwXPRElsPvoJCAbJ5aNXFzwHlQJtU5BhaC1YZhicM2Mq/Z9PcTrSZ4oooY92G6ohB +QroLRfvaRlkWMEONAFMw+Xp4Og4adOGgpnyWSnMR7AgcjZkzgc9/T0WJtl7NYLAK1Sw +JWCmCTfHTs5yiGTYww+bfqmvUiJ5t9CryTcNoSglCGxHXqOYDuUeQ6yix1mY+WhyyD4 PWUg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1674744181; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=U7H+frkBfMS/QfDNx+miiTVXsRSG0C5dzwZ0xkJdXnA=; b=LK8JpRI16dDkvVeBhSCnGDAM0Miw2jPHeSggnp7ML2114kikhozfZN1uQ6qfAYYokC LUmpc7ULoeInOHFPTPbwl2DHVic7J/nrIdO97kGRDt6DbEyK+dhaZBpY32a2pirg0Gjv DCfGcEegKG10h4A1MVQc9iT7/sPkScxRqPjiNU375NEtoyCOJzwymwSMz+kUt5owdqQV JXYpW9MZs/G6YQjU3NCALE0xXHLFaA5mLVWXkV32HYVI3il6Cbx8qgvglTadLpA9zu2C bc16oNOpAUisHRsz2jBHaMicGZHVZi2PYGlCHLPqDT/SJV0NvyogbbOgk4VygC1UK07S ZkZQ== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPE3/AkhaePDzS2RsxjOA78fax83g==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.2.2 AUTH) with ESMTPSA id 098542z0QEh1F6C (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 26 Jan 2023 15:43:01 +0100 (CET) From: Bruno Haible To: GalaxyMaster Cc: bug-gnulib@gnu.org Subject: Re: backupfile and backup-rename are introducing the same object to make Date: Thu, 26 Jan 2023 15:43:01 +0100 Message-ID: <6317250.O3cEFmX14Z@nimes> In-Reply-To: <01000185edcf295e-20bd248f-780d-49da-b9fa-54710fdcbec6-000000@email.amazonses.com> References: <01000185e8d1146f-84242ea5-e0a3-406f-8126-b306b40107f8-000000@email.amazonses.com> <3002907.JBgfCQoYGg@nimes> <01000185edcf295e-20bd248f-780d-49da-b9fa-54710fdcbec6-000000@email.amazonses.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.219; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org GalaxyMaster wrote: > follow the libtool > recommended approach on library versioning (when revision is incrementally > changed on any change, age is incremented on additions, and current is > incremented on interface changes). Despite gnulib's changelog is good in > this regard, I am still thinking of finding an automated way to monitor this; Unfortunately this typically involves developer knowledge about the package. There is some helper script gnulib/build-aux/libtool-next-version that helps avoiding mistakes when assigning the LTV triple of a shared library. It looks at the "nm" output of the library in the current and in the next version. But it still requires judgement: When a function's implementation changed in such a way that its results will change, are these modified results a "major" or a "minor" change? And when you say "ok I'll try to err on the safe side, if in doubt I'll bump the major version", then it's an effort for the distro because they have to rebuild some more packages. Cf. https://lists.gnu.org/archive/html/bug-libunistring/2022-12/msg00001.html > 2. do a sync quarterly aligned with the release of a new version, which > includes rebuilding everything. Note that it's quite frequent that changes to gnulib are being made in the prerelease phase of some other package. For example, there were some gnulib changes yesterday for the GNU poke 3.0 release that happened today. If you have a quarterly schedule regarding gnulib, it means that you will have to wait until 2023-04-01 until you can package poke 3.0. (You'll decide whether that is acceptable for your distro. I'm just giving you a heads-up.) > > You need to think about how you will handle these changes. > > Thanks for kind words, I do consider these and thought quite a bit on the pros > and cons. Maybe we can get some advancement if you describe why, in the first place, you want to do this package "surgery" in the first place. I don't want to judge what you are doing; I wish to listen and understand if on the Gnulib side we can do something a little bit differently, so that it would help regarding your points. > In the end, I found that it would be more efficient to spend time on > one of the two approaches described above rather then try to hunt down each > individual package that introduces local changes to GNU gnulib they are > bundling. E.g. make (https://git.savannah.gnu.org/cgit/make.git/tree/gl) and > coreutils (https://github.com/coreutils/coreutils/tree/master/gl/modules) are > extending the GNU gnulib, some packages (I cannot easily recall the names) are > introducing non-GNU modules or patched versions of gnulib's modules, etc. > > From the system engineering point of view, it is more viable to perform a > "surgery" on a package once, when it is entering the build queue and strip it > off its ties to the bundled, perhaps hacked version of gnulib and convince > package's build system to use a centralised, verified copy. You say "centralised". Why is it a problem if, e.g. GNU make uses some set of (possibly modified) gnulib modules, and GNU coreutils another set, and they use different versions? Binary code size / efficiency of using the RAM? You say "verified". Why is it a problem if some GNU package has decided to modify a gnulib module? This is supported, see https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html Are there reasons not to trust the modifications done e.g. by the GNU make maintainer, when you do trust him for the other parts of the GNU make source code? Bruno