From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 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 DB6831F9F4 for ; Mon, 6 Dec 2021 01:20:45 +0000 (UTC) Received: from localhost ([::1]:34242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mu2gN-0001C3-HT for normalperson@yhbt.net; Sun, 05 Dec 2021 20:20:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mu2gD-0001Bq-F9; Sun, 05 Dec 2021 20:20:33 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.162]:20678) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mu2gB-0001ku-E5; Sun, 05 Dec 2021 20:20:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1638753622; 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=X/VA4RqpkxaG6H1jw6tmmVEEmrTvDbUjx4nxMezzRDM=; b=add/g93tZf6kzfbPtsdEEEtOZ4oZV8cE9idaGGNanoiZBmNxqL6cMkdk/AyYrtl7va QdIMiTyPIoOg4KSCZ6MTrokJXiMaAoGYOX+/4M6cyyYnYBfPHWrmnGpRkIB3+I1L6gCC DbgKlTygu0J94WHoHO4BMnhxjFmn3BopcJrH6D9vHsonVSYYsTm0O9C0jiHKM4rGwOnp owlVf9+7iIGk800456Jh0GW5g/BbgIWquDiNakBeisJy/CQHLLrwyPDn973JJ9UdDi4f Updwjkc58YHsmQFBVtebfznRfq5WZPwKuXeK3+jHOEPwnoQ0jLYr5AQRVGSzll+7uGoS miaw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94z26ll5ip69rlBI2tC7+KI6wwH5KI+m1sato" X-RZG-CLASS-ID: mo00 Received: from omega.localnet by smtp.strato.de (RZmta 47.34.10 AUTH) with ESMTPSA id z050d5xB61KL1nx (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 6 Dec 2021 02:20:21 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: Prefer AM_GNU_GETTEXT_REQUIRE_VERSION? Date: Mon, 06 Dec 2021 02:20:21 +0100 Message-ID: <4790470.KnAXcdumGx@omega> In-Reply-To: <87ee76wshq.fsf@latte.josefsson.org> References: <87ee76wshq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.162; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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: , Cc: Simon Josefsson , bug-gettext@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" [CCing bug-gettext] Simon Josefsson wrote in : > Hi. This may mostly be for Bruno, but I believe it is more relevent to > gnulib than gettext, even though it is gettext-related, and maybe others > on this list can provide feedback too. > > I got a bug report that suggested using AM_GNU_GETTEXT_REQUIRE_VERSION: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999510 > > The suggestion boils down to: > > -AM_GNU_GETTEXT_VERSION([0.19.3]) > +AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.8]) > +AM_GNU_GETTEXT_VERSION([0.19.6]) I don't understand the use-case of AM_GNU_GETTEXT_REQUIRE_VERSION; and it's only half documented (not listed in the TOC, not listed in the autoconf macro index); therefore I cannot recommend to use it. > Libidn2 (and many other packages) contains: > > AM_GNU_GETTEXT([external]) > AM_GNU_GETTEXT_VERSION([0.19.3]) > > Reading gettext NEWS suggests to me that 0.19.8 fixed something for > musl, and that this gettext fix is what is needed to build packages > using gettext on that platform. Am I understanding correct? The NEWS entry says: - The AM_GNU_GETTEXT Autoconf macro can now detect musl-libc's gettext as a compatible implementation. Since this was a change in the gettext.m4 macro (as opposed to the runtime code), yes you need to do something in order to make your package build well on musl systems. I would suggest to just replace AM_GNU_GETTEXT_VERSION([0.19.3]) with AM_GNU_GETTEXT_VERSION([0.19.8]) > If so, my usage of AM_GNU_GETTEXT_VERSION([0.19.3]) seems indeed > problematic because it leads to a too old gettext infrastructure being > pulled in. It would be nice if my package used the latest available > gettext files during bootstrapping, so I should use this: > > AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.6]) > AM_GNU_GETTEXT_VERSION([0.19.6]) If you do this, different people who check out your repository and build it will get different configure files - some with gettext.m4 0.19.6 (which does not include the musl fix), some with 0.21, some with intermediate versions. I wouldn't go down this route, because the difference between what the different people get is hard to track down. > Why > wouldn't you want gettext to use the latest available infrastructure > files? The situation seems similar to libtool's M4 handling. Because if e.g. you are the main developer, and another person is the release manager, you don't want the release manager to release a source tarball that is significantly different from what you have tested all the time. > Thus I would prefer to write a 'make syntax-check' rule to catch this, > and suggest that all packages should use AM_GNU_GETTEXT_REQUIRE_VERSION > to get latest gettext files included in them. You are free to do so. But I would not do that. And certainly it should not be done in Gnulib's maint.mk. Bruno