Received: (at 73769) by debbugs.gnu.org; 15 Oct 2024 20:23:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 15 16:23:24 2024
Received: from localhost ([127.0.0.1]:57637 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t0o4h-0008Ie-HZ
for submit <at> debbugs.gnu.org; Tue, 15 Oct 2024 16:23:23 -0400
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.160]:46621)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bruno@HIDDEN>) id 1t0o4f-0008IB-EP
for 73769 <at> debbugs.gnu.org; Tue, 15 Oct 2024 16:23:22 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1729023780; cv=none;
d=strato.com; s=strato-dkim-0002;
b=qHYIU7dtC5w11ZtIIMfsmsSJGyRmpChtTVf2urTMw456pK45yc8/Oxv6gBgN4Ls9T9
67wd7ProqPZMZUX73tQDG6pttpKEiOKTVwSf76b30OISFJOMcz8tEX2i7/jRYbOUTAbp
IRd6ylOpaoccpQNIt4ya1fLYChuiLgAwS1GjiJApoac+L1wLH/O+NdAQ/e5M+PVOG9Yz
3gv2X4iLnS+ZgqS5fp7ZPnaqoekABhE+Crsa1jx0Ap2C+r/gA2nX5imvxTA3qf9oO4nQ
/EZe8Plkuc7yJ508ExK9Hy9Rhwiin1bbZvxkE/q7CpfhdimoeXVFs8qePfCb1VHbeeXD
Oqag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1729023780;
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=k1NDgq9nTy5JKBP6/xIcFHoFytm5IbE1uVt8Xx58TSo=;
b=m4LM7I+wbOYYVz1ApgY+Ohafrab0gGfrjBYsdfhrffEk4goG6OuSdVm/jJ5SrWD4lt
fr95P2ptuFMtk4dgOOH3e3C7FVAI5cLSOTitWvXRfXTLbIZVdaCglBsa0dfDcyYsnDgn
LezxZWbZEGMyBcP2P77ypgdA08daVPuYGK/uM8BMpJEsWLvHLxnlwqr5RXGAdh5DVuJ0
y0AL7YV+bPcBAclJLAVp96Bok6vdWSS6/xW4uiWBgljzjmhKP8vUC7SJxfwNNUltrSmv
JyWWDjkhK6SaxEYfHwZGRXc83Iww+nYhGgPIwOcj5pc4wZ4C2a4xEldr3SCh8lL3hBpY
45PA==
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=1729023780;
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=k1NDgq9nTy5JKBP6/xIcFHoFytm5IbE1uVt8Xx58TSo=;
b=QDV/yKWC9jDulI6luYiXlDaAAbNB02yIiG/foRDP0VIwDJUJROE1NvWrtAg3LMPGse
bzqWXXX/IbtXIF9ZCloIqJbLTI+hEwMNFGfKvQ0E/RrOrT+4hN8vPF8xBNhv4DV1PJXR
lpP1/+s8+wDUK87yisqR/sulLnUKOtAtoFMDo/Xadz2nZbnlOoS9/h1MZnmx4hpRXML7
GzHWs1WLcUUXDPbtyViKjJuJS2ZrMtMSjWDYpOBhXtr8wpDDSnT2+a9TjIOsUAAKKDq9
chOamURarKg3Ymstr7dsfNs4aTmhNDL/3nuaNDUhcUzvbRVyqgbENTXNH2H/dXgesUxh
OIJg==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1729023780;
s=strato-dkim-0003; d=clisp.org;
h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date:
From:Subject:Sender;
bh=k1NDgq9nTy5JKBP6/xIcFHoFytm5IbE1uVt8Xx58TSo=;
b=dcKLeNNhruT5h0FAwEvhmAkgPoVWrNpuoEUp2XHBQqnko6P/87MPtw9mwEx+mJDLXW
eUImtR/tHrWi2qMxtdAg==
X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlLnY4jECd2hdUURIbZgL8PX2QiTuZ3cdB8X/nqmbNE2pnXrrOnJUesgoSuN9RONb9"
Received: from nimes.localnet by smtp.strato.de (RZmta 51.2.11 AUTH)
with ESMTPSA id Nd105a09FKMxKW5
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
(Client did not present a certificate);
Tue, 15 Oct 2024 22:22:59 +0200 (CEST)
From: Bruno Haible <bruno@HIDDEN>
To: Michael Pratt <mcpratt@HIDDEN>
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
Date: Tue, 15 Oct 2024 22:22:59 +0200
Message-ID: <4900906.JsnAkG3lO3@nimes>
In-Reply-To: <S07lnMgJLG8jGo48rCMEAYkh47DuhCs8HNw5YpN6iRtonDVrB9Js6gL4jhr8pCCcIrskPvW2-u9Aqr2xiS24Tf1al9Nn94M80bvnsx307n8=@pm.me>
References: <202410122057.49CKvHCu1531878@HIDDEN>
<3271062.l52yBJDM9G@nimes>
<S07lnMgJLG8jGo48rCMEAYkh47DuhCs8HNw5YpN6iRtonDVrB9Js6gL4jhr8pCCcIrskPvW2-u9Aqr2xiS24Tf1al9Nn94M80bvnsx307n8=@pm.me>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 73769
Cc: collin.funk1@HIDDEN, =?ISO-8859-1?Q?P=E1draig?= Brady <P@HIDDEN>,
73769 <at> debbugs.gnu.org, karl@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Michael Pratt wrote:
> Specifically, not that any re-generation "should" be done,
> but that users of the tarball should have the "ability" to.
> And like I said, I think we still agree on that...
Yes, we agree on that.
> > I'm glad that you are realizing the big mistake you were doing: Based on
> > discussions (only discussions, not even a committed patch!) with 1 single
> > package that uses gnulib, you wanted to modify the way gnulib works for
> > everyone. And that without even CCing the gnulib people!!
>
> Big mistake? really? what happened?
> ...
> I assumed that I can trust the maintainers here
> to CC whoever they feel the need to CC (including those in the same organization)
> in order to gather the comments they need to make the right decisions...
> and yes, they did rightfully CC you... so is it a bad assumption?
It was a bad assumption. Karl was diligent enough to CC me as one
representative of the Gnulib people. But not every package maintainer
has such a broad view of the big picture and how the packages interoperate.
It is therefore *mandatory* that when you propose a change regarding how
packages X and Y interoperate, you discuss it with both the maintainers of X
and the maintainers of Y. Discussing it with the people of X while leaving
out the people of Y is *not acceptable*.
CCing two or more mailing lists is the right thing to do, in such situations.
> I don't intend to circumvent any channels of communication or procedures.
Good. Next time, ask yourself the question: Who is affected by my patch?
These are the people that need to be included in the discussion.
> I got "something" to work, and I wanted comments on what I had so far.
> Maybe I have some advice for myself...
> should I have added WIP (work in progress) to the subject? like "[WIP PATCH] ..."?
Definitely, yes. Your submission [1] gave the impression that it has been
tested and discussed and is ready for everyone to use.
If the patch is not ready for everyone to use, you need to say so. Like,
when I provide patches, I say whether I have tested them, on which platforms
I have tested them, and if I view them as not-yet-complete.
Bruno
[1] https://lists.gnu.org/archive/html/automake-patches/2024-10/msg00000.html
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 15 Oct 2024 16:05:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 15 12:05:27 2024
Received: from localhost ([127.0.0.1]:56605 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t0k34-0003EG-KE
for submit <at> debbugs.gnu.org; Tue, 15 Oct 2024 12:05:27 -0400
Received: from mail-qt1-f175.google.com ([209.85.160.175]:45436)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <nbowler@HIDDEN>) id 1t0k32-0003Az-UA
for 73769 <at> debbugs.gnu.org; Tue, 15 Oct 2024 12:05:25 -0400
Received: by mail-qt1-f175.google.com with SMTP id
d75a77b69052e-460407b421bso43156501cf.3
for <73769 <at> debbugs.gnu.org>; Tue, 15 Oct 2024 09:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=draconx-ca.20230601.gappssmtp.com; s=20230601; t=1729008241; x=1729613041;
darn=debbugs.gnu.org;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:to:subject:user-agent:mime-version:date:message-id:from
:to:cc:subject:date:message-id:reply-to;
bh=/whUf8PFNQK5G+U8pS+bFaxQhRatXM4iR1HYa2LsXSU=;
b=KGQnMcluJQsP6Zhke1UzH3UbTbMwPRcbTwLyZ2jD3+ufMaTuLkyTgEchgrxwRLyVXB
Rk2BpbETbuned3+QkGmq5w7+jBAwNTRRD4FS4AYJ7Ro2gci5BWYGZAkPwH+252eGcRzL
bOY2ntXoU6WLGZbTC39Fqnicy87PElFOelDA4VEmy0HxzGrZcUNRf1MgmsoR6/vPuYW0
dOf/+8prHKt8XojxjgkC1eIJvXfWrT8wkjnurhSGBGioxs513SbtkAwzRNC4AMwxRnWp
IXiBEnmQQhQ4dggKvLtR44PgG1LyfEqkUwtCvgRq+w9fW0JlOlD0ZmQaPOXdIFJELlom
HymA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1729008241; x=1729613041;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=/whUf8PFNQK5G+U8pS+bFaxQhRatXM4iR1HYa2LsXSU=;
b=HA38eBgxoYPpUTxbZCZ0nu8+jaBJv3Hk/CX2GVdM5Al8Ohgc+rzHnI/lI5ADhBNCov
L1s8cTiFNEM5qdVHjUP9ZzC4Qvh/N/lT1kn9Ue16m2KZWpX3DkNfUgVCViUr0okPfMqL
0sHsA6lt81/W9bJXEuwj69KdA0JHBWSya3SUiGdRYownf9UNEH1JxKXKY5FadIrGXI5I
JVGFLolILjhAsEJuBVd8Fn5WWYeRmcD89Yjn/3lVY0aGrGTIaVHKnxRNJSRqSdDuawnf
BFPxgDjWqyV45ssX3KC9jD/Se4XaAlpyLxnejadtsIyMcvakQHTMRTl9TgqpajP+Phjr
v7aw==
X-Forwarded-Encrypted: i=1;
AJvYcCWq2i7LVHj56zsqytCXlEGuGOWk+6exH9qCs7vT0+t5G3TKKcxjqhi8gGiNsu6I9Px6M45HZQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz6FOLYJqRnyEXRdb3/ynkFpVOxAn67OUVCGUTodsOIbka5d7Vn
jJ44t7DQEpBU3wfym/57rpITjyF5oFDDgDoi9aDURmnwZP5H5Shs0B1pcow8VYvOb/VF8yMVxUu
0
X-Google-Smtp-Source: AGHT+IF9HhVGPRAb637oJN6qN0piq8Cph9gPdKK3iVXz/bvm2hh9NSyOieo7MdtJLfG858+25XTlyg==
X-Received: by 2002:a05:622a:4009:b0:45d:8513:f29d with SMTP id
d75a77b69052e-4604bbb96c9mr218939601cf.20.1729008240403;
Tue, 15 Oct 2024 09:04:00 -0700 (PDT)
Received: from [192.168.0.51] (dhcp-24-53-241-2.cable.user.start.ca.
[24.53.241.2]) by smtp.gmail.com with ESMTPSA id
d75a77b69052e-4607d89942csm7484701cf.54.2024.10.15.09.03.59
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 15 Oct 2024 09:03:59 -0700 (PDT)
Message-ID: <dac59c0e-5e92-47b9-80f7-a6539f7ef626@HIDDEN>
Date: Tue, 15 Oct 2024 12:03:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
To: Michael Pratt <mcpratt@HIDDEN>, 73769 <at> debbugs.gnu.org
References: <20241012102824.4629-1-mcpratt@HIDDEN>
Content-Language: en-US
From: Nick Bowler <nbowler@HIDDEN>
In-Reply-To: <20241012102824.4629-1-mcpratt@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 73769
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2024-10-12 06:29, Michael Pratt via Patches for Automake wrote:
> When gnulib-tool or a bootstrap script uses the option --local-dir,
> include the "modules" files in a release with DIST_COMMON. Otherwise,
> these source files are present in checkouts but not in distribution.
I agree that missing these files is a real problem. A source tarball
should include all the necessary source code.
Users should not be expected to track down random upstream development
repositories, which may not even be publically accessible and probably
contains source code for many different versions, just to find the
source code that corresponds to their version of a particular package.
> The resulting gnulib.mk from gnulib-tool has comments
> with the options used to generate it:
>
> # Generated by gnulib-tool.
> # Reproduce by:
> # gnulib-tool --import --local-dir=gl \
> # ...
Please note that --local-dir option to gnulib-tool can be specified more
than once to add multiple directories which are searched for files in
order. I don't think your regex will work properly in this case.
The local dirs are recorded in machine-readable form in gnulib-cache.m4,
this is where you should be looking for it, not parsing out comments.
> + if ($_ =~ /--local-dir=([^\\\s]*)/o)
> + {
> + push_dist_common ("\$\(top_srcdir\)/$1/modules")
> + if -d "$1/modules";
> + }
Files in a local directory will supersede almost any file from the
primary gnulib sources. It can contain much more than just a "modules"
directory, including per-file patches which are applied on top of what
gets copied in from gnulib. So I think this is not enough to ensure
all the sources are actually included.
For automatic distribution, this problem should probably be solved in
gnulib-tool, as only it knows which files from the local directories
were actually used. All it needs to do is all all these files to
EXTRA_DIST in the generated makefile snippet.
For my own packages, given that gnulib-tool does not do this today,
I solved this particular problem by:
(1) Each local module file includes m4 code to update a global m4_set,
listing all the source files it requires (including itself).
(2) At autoconf time, m4 reads the gl_LOCAL_DIR setting from
gnulib-cache.m4 (a colon-separated list of directories)
(3) At make time, a dist-hook takes this set of source files and list
of local directories to find and distribute the required files.
(4) At release time, checking that gnulib-tool --update works as
expected in an unpacked release tarball.
Obviously it would be easier if gnulib-tool did some of this for me
but the process seems quite acceptable overall.
Cheers,
Nick
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.Received: (at 73769) by debbugs.gnu.org; 15 Oct 2024 14:44:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 15 10:44:09 2024 Received: from localhost ([127.0.0.1]:56064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1t0imO-0006sT-IM for submit <at> debbugs.gnu.org; Tue, 15 Oct 2024 10:44:09 -0400 Received: from mail-40134.protonmail.ch ([185.70.40.134]:49717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mcpratt@HIDDEN>) id 1t0imK-0006rm-VS for 73769 <at> debbugs.gnu.org; Tue, 15 Oct 2024 10:44:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1729003419; x=1729262619; bh=MyJmD8A/CR6YvW/JcRgcj0ssnIQGBAg1ftLUinzqJAA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=cOTuP8DP9+Vt2uLYlJFqkhzO+akDl6z/7z5blPl0wYLHRKsGkxmWShDdWHze6jwV8 Nw18TdEEKau6bY347BqH191TezYGIVBgGKoQ9b4hG7xDrmGI/wc598s6e/wxW+I2EH t6TI2OzliBv5dHvO8JyRViqfY/s/N2rpHsO1BuFc/Ed0U78vDPeFEjwsllw5V8MrGK QTJ5NQUcCHGScxzfbicDhRFgZIPblMf4EGoMG89cbaaNi4ASdrkDlh+Q/wYHKDCLRD XxtoDYzP6P/h39B7jdoUP7M57l+p0Y7HeQFa+WTKnvMvhZYIFVTkq7PRV44KO70Rzp SRIoZYdT/sImQ== Date: Tue, 15 Oct 2024 14:43:35 +0000 To: Bruno Haible <bruno@HIDDEN> From: Michael Pratt <mcpratt@HIDDEN> Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory modules Message-ID: <S07lnMgJLG8jGo48rCMEAYkh47DuhCs8HNw5YpN6iRtonDVrB9Js6gL4jhr8pCCcIrskPvW2-u9Aqr2xiS24Tf1al9Nn94M80bvnsx307n8=@pm.me> In-Reply-To: <3271062.l52yBJDM9G@nimes> References: <202410122057.49CKvHCu1531878@HIDDEN> <2742558.uZKlY2gecq@nimes> <IbD5S2o1s1LmWTvHZ2K1_GPt17iEFvHeuHbYKaGcPFAcXk0p-M8i3b5HKhpP2XFzTMnD8iQDS4pgjnKVViAGLxGimU6JG2EAOEEwuM-LfMQ=@pm.me> <3271062.l52yBJDM9G@nimes> Feedback-ID: 27397442:user:proton X-Pm-Message-ID: 582ebb0d78c819dc968d91867b80a75ea54b06a6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73769 Cc: collin.funk1@HIDDEN, =?utf-8?Q?P=C3=A1draig_Brady?= <P@HIDDEN>, 73769 <at> debbugs.gnu.org, karl@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi again, On Monday, October 14th, 2024 at 05:47, Bruno Haible <bruno@HIDDEN> wrot= e: >=20 >=20 > Michael Pratt wrote: >=20 > > I believe many of you have read this already. > >=20 > > https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html > > ... > > So hopefully we all agree that in general this should be done, >=20 >=20 > No, not everyone agrees with Simon's "de-vendoring". In particular, I dis= agree > with the "Pre-generated files (e.g., ./configure) should be re-generated"= part, Sorry, let me clarify... When I said "we all agree that in general this should be done", "this" refers to the topic of this thread and the goal of my (bad) patch, in that local modules file should be distributed, and not referring to all of the points made in the letter that I linked, but maybe some of them. I was just pointing out the similarity to some of the ideas there. Specifically, not that any re-generation "should" be done, but that users of the tarball should have the "ability" to. And like I said, I think we still agree on that... > because it invalidates the pre-release testing done on the tarball. not sure what you mean... doesn't it just increase the amount of operations= tested? > > I'm glad that you are realizing the big mistake you were doing: Based on > discussions (only discussions, not even a committed patch!) with 1 single > package that uses gnulib, you wanted to modify the way gnulib works for > everyone. And that without even CCing the gnulib people!! > Big mistake? really? what happened? Nobody "accidentally" merged anything, everyone rightfully brought up a concern or questions... The mistake is that the patch itself is bad, not that I used a patch to start a discussion. And that's all this is so far, a discussion. So we are now just deciding whether making it automatic is appropriate, and if so, which tool should handle making it automatic. If an idea is simple, good, and universal enough, it absolutely can just apply to everyone. It's still up to you to decide, sending a patch doesn't make that decision for you. I assumed that I can trust the maintainers here to CC whoever they feel the need to CC (including those in the same organiz= ation) in order to gather the comments they need to make the right decisions... and yes, they did rightfully CC you... so is it a bad assumption? If there were any instructions on who I should CC, and when, I never saw th= em. >=20 > Really the way to do such a thing in a socially acceptable way is to > 1. discuss with 1 package, > 2. get a patch committed for that 1 package, > 3. get in touch with the gnulib people to see whether it generalizes > maybe to some other packages, > 4. only if it turns out that it generalizes to all packages, come to > Automake and ask for an Automake change. It's really just a coincidence that I started experimenting with automake f= irst. I don't intend to circumvent any channels of communication or procedures. I just happen to think of it before considering modifying gnulib-tool. This is before I knew whether sending a manual patch to coreutils would be helpful, or just a waste of time just in case someone else is already writing a patch at the same time I would be. I got "something" to work, and I wanted comments on what I had so far. Maybe I have some advice for myself... should I have added WIP (work in progress) to the subject? like "[WIP PATCH= ] ..."? Maybe if I had the vast knowledge and experience that you do, I would already know the appropriate process of which scope to attempt a change and follow the order every time, but I don't. I also cannot read your mind, so in order to find out whether I'm on the right track, you would have to see what I have... It would be nice if I can tell myself what's wrong with it, but that's not my job in a review process, it's yours. Please simply reject the patch and tell me why and what to try next plainly= , and if I'm in the wrong place, where to go, after I had a chance to make my own arguments, whether they're good or bad. There's no need to relish in pointing out that I'm an amateur. -- MCP
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 14 Oct 2024 20:06:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 14 16:06:55 2024
Received: from localhost ([127.0.0.1]:44445 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t0RLD-0003Tm-Hv
for submit <at> debbugs.gnu.org; Mon, 14 Oct 2024 16:06:55 -0400
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.218]:37393)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bruno@HIDDEN>) id 1t0RLA-0003Tb-KV
for 73769 <at> debbugs.gnu.org; Mon, 14 Oct 2024 16:06:53 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1728936391; cv=none;
d=strato.com; s=strato-dkim-0002;
b=qt8VefeVAaJu8X2xXQBXK5a5pjU/QmUGV0JpsRV7aSkbugLhk43antLhP4D1rbl5VA
DeSxuxCUI7Niebc4N1MuZRCjOZfUfjoqnAf2ulYp+EruBWzsVWDN7I+whWRHcQdNYCaO
eraG3DqaBalL1p6uZbTyCfI8E3BqV4hznTOv3FFEg6m2U69oyiDHu+6c7LgjroQUpAie
y7NoIqrGtkegL4jekKu8ETyceN7CVt3tKXvUU25pcMfrA38Jx2iY9N9saGf3mkZjLlYM
XPuk8aydnoGMb6lcIdoYJl2bfHXjr7Jx8Y9f+s77qviF2NQOsFQKKcWWPeWLV0sXK+Ir
m7Wg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1728936391;
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=m+lx2PtnudnR7aVNn9vpQtAbpAUldCAImK8jQ7mnnns=;
b=CcoZmGDCPAP6uQoy+JWEquTl0BpyN6p5WCToeW8J7Sj05zlWr0uqdgYOQ5lhSnCcYT
OE5k0d07prMHTiAlI5hNcwo2TZ2/ef8jRsvOvB9RSpSY3+TDZnnEQv83J4bmdb+EMh/X
c0NXTeVxc5ajpzb8ErPjWBsLW1JjvQAE7s1DL/LuwVCFrnKhaQnAht6C1sDe7MSh+tAa
1mD9ttIK+ENakv6iGKoKwCYhXZKlNyqvhlyGIKl8qUzq5+hPUQfdqZLIzBh8pz4VzxwR
bBbzbUyZveqJANyCoMBMasUql5tB9cRqhzU3vXhcACw8GV2qHOZGNJiCPG5kjebdhmK7
4lEQ==
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=1728936391;
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=m+lx2PtnudnR7aVNn9vpQtAbpAUldCAImK8jQ7mnnns=;
b=ESUu+DlveZAk/vS8Q8j14+oxuET6h0s6IXIlrG9n/rYPbAixKrjUdVhEFbcZCVIp4/
5fKYS7y+GS8wlcm+7BurqxBa0asvOEkqxUZH19/K+4TsMmplbn5cGdhT6SCtGA7FZAJY
MRgIPpP4TVr3Yn7fOOI76QzOxSAtKaL70CZhIsSl/M9BWuVBOKJcZ46S2BKXWd4qFF5X
nyjN8Id+ymvnjswSBJ+PXWYJNQKeHPy2m/xu7BdcvouJlhKRYw5KEYLZTjGmdebHG9k/
hbiGrNtPX+vbLjr1wOMV+yzE3WAW66CYY0ZXpK3ohHQbU0MvPJlyo1fAE0rPu0Fu41hP
u6xQ==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1728936391;
s=strato-dkim-0003; d=clisp.org;
h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date:
From:Subject:Sender;
bh=m+lx2PtnudnR7aVNn9vpQtAbpAUldCAImK8jQ7mnnns=;
b=D5hlymQXynnuLUf6XfmUCFaHmgE4nKiiLowrZIa1qvJt2NO6U1LLxi75mKlEEohq+O
u9nbBdpl+Rc+u4rAhzBQ==
X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlLnY4jECd2hdUURIbZgL8PX2QiTuZ3cdB8X/nqjuaEjsVvdKtzjjTsB98UoFq+8M4"
Received: from nimes.localnet by smtp.strato.de (RZmta 51.2.11 AUTH)
with ESMTPSA id Nd105a09EK6VDf6
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
(Client did not present a certificate);
Mon, 14 Oct 2024 22:06:31 +0200 (CEST)
From: Bruno Haible <bruno@HIDDEN>
To: mcpratt@HIDDEN, Karl Berry <karl@HIDDEN>
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
Date: Mon, 14 Oct 2024 22:06:30 +0200
Message-ID: <12905332.iMDcRRXYNz@nimes>
In-Reply-To: <202410141954.49EJseSb1721742@HIDDEN>
References: <202410141954.49EJseSb1721742@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 73769
Cc: P@HIDDEN, 73769 <at> debbugs.gnu.org, collin.funk1@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Karl Berry wrote:
> automake processes the output of gnulib-tool as an input.
>
> It does? I'm not aware of this. If I grep -r gnulib-tool in the automake
> source dir, there are no results.
gnulib-tool not only copies source files, but also generates some Makefile.am
files [1][2]. Automake processes these Makefile.am files.
Bruno
[1] https://www.gnu.org/software/gnulib/manual/html_node/Modules.html
[2] https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 14 Oct 2024 19:55:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 14 15:55:22 2024
Received: from localhost ([127.0.0.1]:44424 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t0RA1-0002qT-VL
for submit <at> debbugs.gnu.org; Mon, 14 Oct 2024 15:55:22 -0400
Received: from frenzy.freefriends.org ([198.99.81.75]:51716
helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <karl@HIDDEN>) id 1t0RA0-0002ph-D4
for 73769 <at> debbugs.gnu.org; Mon, 14 Oct 2024 15:55:21 -0400
X-Envelope-From: karl@HIDDEN
Received: from freefriends.org (localhost [127.0.0.1])
by freefriends.org (8.16.1/8.16.1) with ESMTPS id 49EJsfqW1721743
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);
Mon, 14 Oct 2024 13:54:41 -0600
Received: (from apache@localhost)
by freefriends.org (8.16.1/8.14.7/Submit) id 49EJseSb1721742;
Mon, 14 Oct 2024 13:54:40 -0600
Date: Mon, 14 Oct 2024 13:54:40 -0600
Message-Id: <202410141954.49EJseSb1721742@HIDDEN>
From: Karl Berry <karl@HIDDEN>
To: mcpratt@HIDDEN
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
In-Reply-To: <IbD5S2o1s1LmWTvHZ2K1_GPt17iEFvHeuHbYKaGcPFAcXk0p-M8i3b5HKhpP2XFzTMnD8iQDS4pgjnKVViAGLxGimU6JG2EAOEEwuM-LfMQ=@pm.me>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 73769
Cc: P@HIDDEN, bruno@HIDDEN, 73769 <at> debbugs.gnu.org,
collin.funk1@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
I don't feel competent to make any general comments, but this statement
caught my eye:
automake processes the output of gnulib-tool as an input.
It does? I'm not aware of this. If I grep -r gnulib-tool in the automake
source dir, there are no results. --best, karl.
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 14 Oct 2024 09:47:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 14 05:47:45 2024
Received: from localhost ([127.0.0.1]:35434 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t0Hg1-0006lm-F8
for submit <at> debbugs.gnu.org; Mon, 14 Oct 2024 05:47:45 -0400
Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.51]:35759)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bruno@HIDDEN>) id 1t0Hfy-0006lW-At
for 73769 <at> debbugs.gnu.org; Mon, 14 Oct 2024 05:47:43 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1728899241; cv=none;
d=strato.com; s=strato-dkim-0002;
b=dE5dEQjq5vDqgX47HWV3wwC5UXfI96jaq9w2jUMNef2Qt23chc8E10WjeDQ7q/kmrr
120CAjsyAN0nETPQFAv1T/2mMQrF05nT8T+oYq76THPPPWm0xM5YJYPe/9uSKlJipTus
r/copXdm3wI6eGbJ2Z1AUzskTgQwYUc02z4vkfUzQ9+KN6uzKVBY3tx/i/4gauQ2UFBk
5cxS/sUKGEgTwLb5McwtNvxz2Eq91r8FY6yY8MoMTIlA182M2rLvEn4+YonjZ6XmTB0P
hh2WlDkHohbQZfZWbEXfjuUCcjruaG+lJAej627xuvTMy0rrXea7/qDKIF8KPhPlDivy
uR6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1728899241;
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=5YGG9pU2Za4nVfjQVBbx6bKFJs0kr1Q7PdJjP9W0ePY=;
b=Be3gApF8xfqpDGj/5viohTG1OZ3pk89uHUoG4tfWYnpvk/or9Tlns8STPNZPJOJ3R8
nAMSeSK/yxr15OAczMLNth8stPWmoRHGHGmRB+11th9IpDmJvkcihseQG+5ijb0KXU7s
JL94hFT2Uk8QBqiS8HqiY0br3ez69CvZwMx0DraSRZZ564uvZoCKZMoG3jjU3p071lv+
3AnKZS58Hgdz52muQ+WXSuudPckLymMUlkWhXL+SsFqcwyIhVSM3aF5CqGZUr84t2gx3
SHzA9W+7kxAJETFVFKAqF8XCe8NH7eS5G4KxcuN7mWI7GyLnNjpiklagv83JL4lEdqI5
3Abg==
ARC-Authentication-Results: i=1; strato.com;
arc=none;
dkim=none
X-RZG-CLASS-ID: mo01
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1728899241;
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=5YGG9pU2Za4nVfjQVBbx6bKFJs0kr1Q7PdJjP9W0ePY=;
b=YZs7sb+qsmG+HklmxCH6+g0l8Bm1ZgyeRxpzk89NTEO220qTl2iybWZQuALWujNV4w
PAK611EdlTsZNdyO8UQ7XdVr99kxlDqe1rSFOZ4KelhBSL2biiX6tyXMVklD6gJydobe
zsHmK8LUpJUdRP/cZa1s+T3NWAhPSY77b/x0TAS9oue/KnWXackVu5ZhR+mvIyP76q8Z
xYasRFzcTOP5tPTE/O6ISjytf05DQpHWmtG1JFmTwEjvBlvS7iY75piL8bRozSZ73NTm
3w5q5t/PJoN9TeV1kN8a4Dfv4tEhACu0fKl3qjqTeiaf56QMRSqXdLjaGIhgUulZYZLF
bLVA==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1728899241;
s=strato-dkim-0003; d=clisp.org;
h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date:
From:Subject:Sender;
bh=5YGG9pU2Za4nVfjQVBbx6bKFJs0kr1Q7PdJjP9W0ePY=;
b=gZFo+8cS89YhEgq6CBxL8J/dJrx86440WGSV3seF6OtzwRHGk50rbhi66A/o/9PKWy
E85kTHHFBiOQv61sISAg==
X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlLnY4jECd2hdUURIbZgL8PX2QiTuZ3cdB8X/nqjuaEjsVvdKtzjjTsB98UoFq+8M4"
Received: from nimes.localnet by smtp.strato.de (RZmta 51.2.11 AUTH)
with ESMTPSA id Nd105a09E9lLAvl
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
(Client did not present a certificate);
Mon, 14 Oct 2024 11:47:21 +0200 (CEST)
From: Bruno Haible <bruno@HIDDEN>
To: Michael Pratt <mcpratt@HIDDEN>
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
Date: Mon, 14 Oct 2024 11:47:21 +0200
Message-ID: <3271062.l52yBJDM9G@nimes>
In-Reply-To: <IbD5S2o1s1LmWTvHZ2K1_GPt17iEFvHeuHbYKaGcPFAcXk0p-M8i3b5HKhpP2XFzTMnD8iQDS4pgjnKVViAGLxGimU6JG2EAOEEwuM-LfMQ=@pm.me>
References: <202410122057.49CKvHCu1531878@HIDDEN>
<2742558.uZKlY2gecq@nimes>
<IbD5S2o1s1LmWTvHZ2K1_GPt17iEFvHeuHbYKaGcPFAcXk0p-M8i3b5HKhpP2XFzTMnD8iQDS4pgjnKVViAGLxGimU6JG2EAOEEwuM-LfMQ=@pm.me>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 73769
Cc: collin.funk1@HIDDEN, =?ISO-8859-1?Q?P=E1draig?= Brady <P@HIDDEN>,
73769 <at> debbugs.gnu.org, karl@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Michael Pratt wrote:
> I believe many of you have read this already.
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html
> ...
> So hopefully we all agree that in general this should be done,
No, not everyone agrees with Simon's "de-vendoring". In particular, I disagree
with the "Pre-generated files (e.g., ./configure) should be re-generated" part,
because it invalidates the pre-release testing done on the tarball.
> even with a release tarball one should be capable of regenerating every build step
> that a maintainer would do.
I agree with that: A user or distributor should be able to pull a tarball,
apply a patch, and re-run gnulib-tool. The need to pull some other git repos
at this point is a problem though. Cf.
https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00239.html
> I have a v2 patch ready if the following arguments make enough sense...
> or perhaps sending a patch to gnulib would be better?
I'm glad that you are realizing the big mistake you were doing: Based on
discussions (only discussions, not even a committed patch!) with 1 single
package that uses gnulib, you wanted to modify the way gnulib works for
*everyone*. And that without even CCing the gnulib people!!
Really the way to do such a thing in a socially acceptable way is to
1. discuss with 1 package,
2. get a patch committed for that 1 package,
3. get in touch with the gnulib people to see whether it generalizes
maybe to _some_ other packages,
4. only if it turns out that it generalizes to _all_ packages, come to
Automake and ask for an Automake change.
Bruno
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.Received: (at 73769) by debbugs.gnu.org; 14 Oct 2024 06:41:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 14 02:41:08 2024 Received: from localhost ([127.0.0.1]:34068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1t0ElQ-00045B-26 for submit <at> debbugs.gnu.org; Mon, 14 Oct 2024 02:41:08 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:24389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mcpratt@HIDDEN>) id 1t0ElN-00044Z-0Y for 73769 <at> debbugs.gnu.org; Mon, 14 Oct 2024 02:41:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1728888041; x=1729147241; bh=uecQYI/VEw0vPBEBE1EXztBdLXQvDU8qojfSW5/EdF8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=STqb52JrS+Mi2X1oxV4b8jeHjiwo7C7iTJpUX9UdneMUdZ/lXL0BnT3euB+6+QssZ NwM4ciTOSnjBsidGNxl/2CTxlq164iwZKRnTtpzaa87zvJGCdyg9YHI8olXBwhHXAe gzA1ZA7Rnf6bFO80xyWb0a/wqg2Zlvu+Bs3DAE8fxqkc5OvOgLlMphSU6Y1EQ1v364 0pW+jLzB/z5o0xyby+ERU/kXseKTdwnAhbgqNfwRuKwT5ZTtuU/nsmIPpJPdaKHLoa +d/f99yf1HN97zdCcbX0oacrkwzWXOb3wrs5tq6E4mvoPJt/vp8HW5AKg8Dv/luegh bTdX6ayrLLSeA== Date: Mon, 14 Oct 2024 06:40:37 +0000 To: "bruno@HIDDEN" <bruno@HIDDEN> From: Michael Pratt <mcpratt@HIDDEN> Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory modules Message-ID: <IbD5S2o1s1LmWTvHZ2K1_GPt17iEFvHeuHbYKaGcPFAcXk0p-M8i3b5HKhpP2XFzTMnD8iQDS4pgjnKVViAGLxGimU6JG2EAOEEwuM-LfMQ=@pm.me> In-Reply-To: <2742558.uZKlY2gecq@nimes> References: <202410122057.49CKvHCu1531878@HIDDEN> <2742558.uZKlY2gecq@nimes> Feedback-ID: 27397442:user:proton X-Pm-Message-ID: a1557a3bdd984f1c4cab49d5fc6828568bb3e26e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73769 Cc: "collin.funk1@HIDDEN" <collin.funk1@HIDDEN>, =?utf-8?Q?P=C3=A1draig_Brady?= <P@HIDDEN>, "73769 <at> debbugs.gnu.org" <73769 <at> debbugs.gnu.org>, "karl@HIDDEN" <karl@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi all, thanks for the detailed response, I had been discussing this with P=C3=A1draig, to at least do this manually, and he shared with me an older letter discussing the packaging of tools that use gnulib and how that affects, for example, debian maintain= ers. I believe many of you have read this already. https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html Even though the concept of local modules is not explicitly mentioned, it's very relevant to the main idea, which as I understand it, is that even with a release tarball one should be capable of regenerating every bui= ld step that a maintainer would do. The problem here, is that a coreutils release, for example, has modules that would not be found in a gnulib release. So hopefully we all agree that in general this should be done, and we're just discussing whether or not making it automatic is appropriate= , and if so, then how best to do it. I have a v2 patch ready if the following arguments make enough sense... or perhaps sending a patch to gnulib would be better? On Saturday, October 12th, 2024 at 18:12, Collin Funk <collin.funk1@HIDDEN= om> wrote: > > I disagree with the patch since it doesn't work for every package that > uses Gnulib. Specifically, it assumes the Makefile name 'gnulib.mk' > which is used by Coreutils. > > In Coreutils' bootstrap.conf file we have: > > gnulib_tool_option_extras=3D"--tests-base=3Dgnulib-tests --with-tests --s= ymlink\ > --makefile-name=3Dgnulib.mk --automake-subdir > " > This is my fault, I was blindsided by lines in the bootstrap script that for some reason made me think that "gnulib.mk" is the default filename= ... For that reason, the patch is no good as it is, but let's consider a possible v2 or another alternative... On Saturday, October 12th, 2024 at 18:51, Bruno Haible <bruno@HIDDEN> wr= ote: > > The patch is wrong for three reasons: > > 1) Inversion of dependencies. > > Gnulib relies on Automake. (And Automake relies on Autoconf. And > Autoconf relies on m4.) If anyone introduces a dependency in the > opposite direction, namely that Automake relies on Gnulib (in the > sense that Automake incorporate knowledge about how gnulib-tool > operates), this makes evolution of both Automake and Gnulib > extremely hard. "dependency" is a really strong word. I would not describe this as such. First, there already is an inversion of dependencies, in some sense, because automake processes the output of gnulib-tool as an input. I don't see much of a difference between automake interpreting the output of gnulib-tool compared to the metadata in it's output. As I see it, gnulib is well enough established at this point that I think a large change in existing options naming or functionality is = unlikely. If it makes you more comfortable, what if gnulib-tool set this with an EXTRA_DIST variable? Second, in the way that I intend to apply this idea, each step of detection is protected by an if-statement, and if any if-statement fails, the default behavior is no change in functionality at all. In case something does change, and the functionality of this change goes from the intended action to no effect, this should be easily discoverable by the maintainer when they attempt to run bootstrap from a distribution tarball, as the build would fail with missing source. I intend for automake to be able to read whatever gnulib produces in a similar way that a human would: "It looks like this project had local modules, but I can't find them in the release, I wonder which directory it is in the project's VCS, let me look at each xyz.mk that becomes input to automake for the one made by gnulib-tool, and read the options." becomes something like "automake finds magic string --local-dir=3D([^\\\s]*), in a file that has magic string "Generated by gnulib-tool", therefore there was a local gnulib module used here, let's distribute the info for the modules but only if the directory exists." > > It is as if the assembler had built-in knowledge of instruction > patterns that a compiler emits. It makes it very hard for the > compiler and for the assembler to evolve. Fortunately we don't > see this mistake in many areas. But in areas where it exists, it > causes major trouble, such as with the 'GNU-stack' section. > ...maybe a better analogy would be "dependency tracking" in which information is stored about how an object was compiled for use after the fact... > 2) gnulib-tool's interface with the package maintainer is that > gnulib-tool, after copying a number of files, makes a couple (5-10) > of instructions for the package maintainer. For example: > > Don't forget to > - "include Makefile.gnulib" from within "lib/Makefile.am", > - "include Makefile.gnulib" from within "tests/Makefile.am", > - mention "-I gnulib-m4" in ACLOCAL_AMFLAGS in Makefile.am > or add an AC_CONFIG_MACRO_DIRS([gnulib-m4]) invocation in ./configure.ac, > - mention "gnulib-m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am, > - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC, > - invoke gl_INIT in ./configure.ac. I was under the impression that these instructions are printed because automake is simply not capable of making these changes for you. This is especially true for the last 2... > > The reason behind this is that the package maintainer MUST remain > the master of his build system. We do NOT want a build system in > which the package maintainer is a victim. > And even with applying this idea, the maintainer is still in control thanks to the dist-hook rule. The intention is simply to make automake a little bit more automatic to make the maintainer's job easier, not to sequester control... In fact, if following the logic of the letter I linked, it would be irresponsible for a maintainer to attempt to block the inclusion of these files in distribution, and whatever else automake already automatically includes is also within the criteria that it's their responsibility to include it. > But in this case, even this would be wrong, because: > > 3) The directory that is the argument of --local-dir is entirely > maintained by the package. The developer decides which of the files > he wants to distribute, and which he wants to keep for himself and > not distribute. For example, it is perfectly reasonable for a > developer to add gl/modules/<module>.diff if he wants to have > a locally modified copy of <module> for his own purposes. > It is not different from subdirectories with C source code, from > subdirectories with data, from subdirectories with unit tests, etc. Whenever I have seen a file like gl/modules/<module>.diff, it's usually to fix a build problem that an end user or packager would equally have problems building without, making the file just as critical to have distributed as the source itself, in the case that the end user or packager needs to re-generate the pre-generated files. If that's not the case, the maintainer should know to clear out modificatio= ns made for "personal use" or testing, etc. before attempting to make a distributio= n. However, if including an entire subdirectory is not acceptable, this too ca= n be reworked as the resulting Makefile.am snippet from gnulib-tool includes the list of = modules which can be parsed just as well as the subdirectory is. I would argue that the "modules" files should be considered part of "the so= urce" just as much as the literal C source files, as you cannot build from scratch without them, compared to files like READMEs where whether one README should be included vs another would be more of a open debate since it has no effect on the ability to build with any method... -- MCP
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 12 Oct 2024 22:51:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 12 18:51:34 2024
Received: from localhost ([127.0.0.1]:37265 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1szkxR-0001R6-Nv
for submit <at> debbugs.gnu.org; Sat, 12 Oct 2024 18:51:34 -0400
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.219]:46815)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bruno@HIDDEN>) id 1szkxP-0001Qr-Ke
for 73769 <at> debbugs.gnu.org; Sat, 12 Oct 2024 18:51:33 -0400
ARC-Seal: i=1; a=rsa-sha256; t=1728773475; cv=none;
d=strato.com; s=strato-dkim-0002;
b=MuvWoOGczUeAP/LbA7O5VpowU+M1snj5PWtW9joOhgWDFTvRagQ5eSYEW3ND68hlhH
5qHR2fmIplm8jTDGvW1MRd301PIsuqSFTg8w5IhlVKnabhqRI46BVuujfxKfxENae2D3
HJgUNSuxOaoyVoAKKEZ27tkBLFstXcxKgh6DdaYNzVkz/F+h7WKVlRsAAPK2oUF5arcW
F1fkGxqRV0io0TIDgfvwg5yuUCPL7FvolT9JAbXCSkaK7rK+dLeatACBeI/O75cRPIAX
NaOBt6Nl5tXZDvo65l4bzJRP7Oc+m3SFUvm9jN/kB8O7q6GjAJl9CgL7I0TaL93s7rxN
+/ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1728773475;
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=3rQIwqyYdbGa6k1T9By94Ve+g1UCLUM6bPP7yTrqCno=;
b=O/WauYPp8YlUyAbeoqmlc2LvRj7s9GSL4Z/ASvES6zW6wBoM1tkf9fXECFBs8KHrlu
rC46zPFs1Zx3s7ZkhlnZMdftdJfiw6EJN605X0Hd6oZo4ORKol/tTKp2P+KETFK4HthF
U1YxfnWWH5XP7QSXpJCWSdvA7swnMy976EcBtDdJcUK/d+qN9zjenW95/DqQcUPs6IwB
Tfnv9xNAm4o0KjTEfL4vAJoIV7c4VbCgZiNJwFjE4pUFU+LWiJB02H82eKnkzmtwHucp
zUzQCwJLgrrgyt+p/o8K9x4QFix4ujzEzjMvwQas8lngt/13flkPvwSrjO601UjPicj6
zwhg==
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=1728773475;
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=3rQIwqyYdbGa6k1T9By94Ve+g1UCLUM6bPP7yTrqCno=;
b=ru2JqJRADLCDSv6q5S36eAkXMk/65L6v6IXICP7cF8/xnsUKB/AaqIqL4tS7hv3bCd
ZQuED6J43N4jBpWaFkTIO3un/S9hUM0ZdfYCMI7fXUgHGwrk6mY/LvM/BFvbLHTfwz20
Xr7vU/GZWxXrqywgADiGyWP0OofQ4tgl9LI/sb7Xn1j8eruy1XkIqAF25Ih+9RT7+WAm
7pHXxFEUtHwCv28SsfdHnrMhoVoMrIOm5mzSzcPkKm5Zs8tSR2vWBJ4CfwOf4uwFf9VR
XfLfJhCppwX8wfP9d+J0PmtnNxWewqm6TEJhhiUY6axnmey3z+f9Zf3YbHNfA3YGUkDf
t9+Q==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1728773475;
s=strato-dkim-0003; d=clisp.org;
h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date:
From:Subject:Sender;
bh=3rQIwqyYdbGa6k1T9By94Ve+g1UCLUM6bPP7yTrqCno=;
b=BuKfZ8u29bCLVu1rH+Dhv72zvIeIOo3KT6SCTbWSXLHr6AmswPR5rPSAy8FsGofBl5
Ik2D30fGqnr5OuueGIBw==
X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlLnY4jECd2hdUURIbZgL8PX2QiTuZ3cdB8X/nqmacEDgppeuRuSpXDNfySwXXX/g="
Received: from nimes.localnet by smtp.strato.de (RZmta 51.2.11 AUTH)
with ESMTPSA id Nd105a09CMpE6pC
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
(Client did not present a certificate);
Sun, 13 Oct 2024 00:51:14 +0200 (CEST)
From: Bruno Haible <bruno@HIDDEN>
To: mcpratt@HIDDEN, Karl Berry <karl@HIDDEN>
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
Date: Sun, 13 Oct 2024 00:51:14 +0200
Message-ID: <2742558.uZKlY2gecq@nimes>
In-Reply-To: <202410122057.49CKvHCu1531878@HIDDEN>
References: <202410122057.49CKvHCu1531878@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 73769
Cc: 73769 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Karl Berry wrote:
> What do others think? Bruno, would you mind taking a look at Michael's
> message? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73769
The patch is wrong for three reasons:
1) Inversion of dependencies.
Gnulib relies on Automake. (And Automake relies on Autoconf. And
Autoconf relies on m4.) If anyone introduces a dependency in the
opposite direction, namely that Automake relies on Gnulib (in the
sense that Automake incorporate knowledge about how gnulib-tool
operates), this makes evolution of both Automake and Gnulib
extremely hard.
It is as if the assembler had built-in knowledge of instruction
patterns that a compiler emits. It makes it very hard for the
compiler and for the assembler to evolve. Fortunately we don't
see this mistake in many areas. But in areas where it exists, it
causes major trouble, such as with the 'GNU-stack' section.
2) gnulib-tool's interface with the package maintainer is that
gnulib-tool, after copying a number of files, makes a couple (5-10)
of instructions for the package maintainer. For example:
Don't forget to
- "include Makefile.gnulib" from within "lib/Makefile.am",
- "include Makefile.gnulib" from within "tests/Makefile.am",
- mention "-I gnulib-m4" in ACLOCAL_AMFLAGS in Makefile.am
or add an AC_CONFIG_MACRO_DIRS([gnulib-m4]) invocation in ./configure.ac,
- mention "gnulib-m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
- invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC,
- invoke gl_INIT in ./configure.ac.
The reason behind this is that the package maintainer MUST remain
the master of his build system. We do NOT want a build system in
which the package maintainer is a victim.
If anyone feels that some adjustments to the build system should
be done, relating to Gnulib, the proper way to do it is to add
another instruction to the instruction pack shown above.
But in this case, even this would be wrong, because:
3) The directory that is the argument of --local-dir is entirely
maintained by the package. The developer decides which of the files
he wants to distribute, and which he wants to keep for himself and
not distribute. For example, it is perfectly reasonable for a
developer to add gl/modules/<module>.diff if he wants to have
a locally modified copy of <module> for his own purposes.
It is not different from subdirectories with C source code, from
subdirectories with data, from subdirectories with unit tests, etc.
Bruno
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 12 Oct 2024 22:14:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 12 18:14:21 2024
Received: from localhost ([127.0.0.1]:36029 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1szkNR-0007RF-9Z
for submit <at> debbugs.gnu.org; Sat, 12 Oct 2024 18:14:21 -0400
Received: from mail-pl1-f178.google.com ([209.85.214.178]:55384)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <collin.funk1@HIDDEN>) id 1szkNO-0007R5-WF
for 73769 <at> debbugs.gnu.org; Sat, 12 Oct 2024 18:14:20 -0400
Received: by mail-pl1-f178.google.com with SMTP id
d9443c01a7336-20caea61132so13833935ad.2
for <73769 <at> debbugs.gnu.org>; Sat, 12 Oct 2024 15:14:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1728771182; x=1729375982; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=hRua127+rEUNBrkm/M6MYE7Z2Jj5mIFoHdXLKQtKGAI=;
b=FiV/MGLVAA8BdiuButBAJ1MRKK3r2w5H68wKEOuQ7QD+974rV897hs8cmpSwcuKUqM
+k0NqW5IBtO8vKNgEGfzEtmh3i7tng5dsY+he4xr5D0psEXharoKC1frg+UPhgYEGTe7
g3CBlYS84xFw+GA29NFtcCBJAyenbaIBYSudFchyOrIp+ZFS/Juk8bAvjul7TS19MaT8
DaFkUwVYMhNz9A6IXoZULYSW/7I6unpZUm2We4oCB6RkOXVJqHCyqgn65NM6VOBGempW
pql+PcF6vW8NfI8feCxnuZaKmRZj/2pZxDfI3vHeB3YYWIO0T/uJtQUthITh+KGpYGEI
+P8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1728771182; x=1729375982;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=hRua127+rEUNBrkm/M6MYE7Z2Jj5mIFoHdXLKQtKGAI=;
b=uMtTars73u36XVrK3A6S2E5UPQRkATBDboavSHxnLgHJeYDzihd3NvjhnDDpOZU4g0
Bnr48/L/9gZrelg03PCPWHTrxfSs8EfhlKgXkJjhSGAIqJIJuiwHEth4rG6JpN3sJwTQ
Rjn7dElXKkqWE0awgd+HOz3iOfK2mdZzd04eGSefTJB9QOb+mzAEFJ5i5JcP4Cogpihw
TJOavAX0pKOjVa27FEblgn4YynmgD4fUCbBxpCelL021d43DTO4CvaGWGBPwDEbts2Yt
nMDYdGGMhPg8ALGciyX81GJ/vcBQoDRBxYwXrxnzeGdpH3b3dMQZ6jymSsZrV25uKphS
pmeg==
X-Forwarded-Encrypted: i=1;
AJvYcCXTALPglu0tNpnXE7zDjR5CCkf1M3GmzK6oaWtSsycmd5YKRaoAuMBzWjqHCeFCLlBSCH8W6Q==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwDr72inKdgvz9rGNYJFSdOVDwCaF9ti0JQRjyWp03ZRQZPKAam
b6esEokJyscMKLfljG7VLQwBmlIjNDfZYVQsGAVjxoykYolGWEAwlP5UaA==
X-Google-Smtp-Source: AGHT+IFLqjaS3Rhfi1J1OI1Z8U0YLzqystasix4+9whYsG+1iBhZVhSxso3JAgfDCnBru9Gclm5NzA==
X-Received: by 2002:a17:902:d552:b0:20c:705b:4123 with SMTP id
d9443c01a7336-20cbb1c6cdcmr59235585ad.21.1728771182319;
Sat, 12 Oct 2024 15:13:02 -0700 (PDT)
Received: from fedora (static-198-54-134-108.cust.tzulo.com. [198.54.134.108])
by smtp.gmail.com with ESMTPSA id
41be03b00d2f7-7ea6c3010ecsm1270803a12.12.2024.10.12.15.13.00
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 12 Oct 2024 15:13:01 -0700 (PDT)
From: Collin Funk <collin.funk1@HIDDEN>
To: Karl Berry <karl@HIDDEN>
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
In-Reply-To: <202410122057.49CKvHCu1531878@HIDDEN> (Karl Berry's
message of "Sat, 12 Oct 2024 14:57:17 -0600")
References: <20241012102824.4629-1-mcpratt@HIDDEN>
<202410122057.49CKvHCu1531878@HIDDEN>
Date: Sat, 12 Oct 2024 15:12:59 -0700
Message-ID: <87ldyt7yxg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 73769
Cc: mcpratt@HIDDEN, bruno@HIDDEN, 73769 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
Hi Karl,
Karl Berry <karl@HIDDEN> writes:
> What do others think? Bruno, would you mind taking a look at Michael's
> message? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73769
I'm not Bruno, but I feel like I know a bit about gnulib-tool. :)
I disagree with the patch since it doesn't work for every package that
uses Gnulib. Specifically, it assumes the Makefile name 'gnulib.mk'
which is used by Coreutils.
In Coreutils' bootstrap.conf file we have:
gnulib_tool_option_extras="--tests-base=gnulib-tests --with-tests --symlink\
--makefile-name=gnulib.mk --automake-subdir
"
The --makefile-name option is explained in gnulib-tool --help:
--makefile-name=NAME Name of makefile in the source-base and tests-base
directories (default "Makefile.am", or
"Makefile.in" if --gnu-make).
> Wouldn't it be cleaner if the packages that use gnulib take care to
> include the gl/modules directory (and anything else needed)? Just like
> anything else.
This would be the correct way to do it, in my opinion.
Collin
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at 73769) by debbugs.gnu.org; 12 Oct 2024 21:45:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 12 17:45:14 2024
Received: from localhost ([127.0.0.1]:36007 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1szjvG-0005t1-J9
for submit <at> debbugs.gnu.org; Sat, 12 Oct 2024 17:45:14 -0400
Received: from frenzy.freefriends.org ([198.99.81.75]:40230
helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <karl@HIDDEN>) id 1szjvD-0005sq-PI
for 73769 <at> debbugs.gnu.org; Sat, 12 Oct 2024 17:45:12 -0400
X-Envelope-From: karl@HIDDEN
Received: from freefriends.org (localhost [127.0.0.1])
by freefriends.org (8.16.1/8.16.1) with ESMTPS id 49CKvHev1531880
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);
Sat, 12 Oct 2024 14:57:17 -0600
Received: (from apache@localhost)
by freefriends.org (8.16.1/8.14.7/Submit) id 49CKvHCu1531878;
Sat, 12 Oct 2024 14:57:17 -0600
Date: Sat, 12 Oct 2024 14:57:17 -0600
Message-Id: <202410122057.49CKvHCu1531878@HIDDEN>
From: Karl Berry <karl@HIDDEN>
To: mcpratt@HIDDEN
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
modules
In-Reply-To: <20241012102824.4629-1-mcpratt@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 73769
Cc: bruno@HIDDEN, 73769 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hi Michael,
* bin/automake.in (read_am_file): push "modules" subdirectory of
local gnulib directories to dist_common if it exists.
Thanks for the patch. I admit I know little about the usual way gnulib
is used nowadays, but my first reaction is that automake should not try
to incorporate hardwired knowledge of gnulib. Wouldn't it be cleaner if
the packages that use gnulib take care to include the gl/modules
directory (and anything else needed)? Just like anything else.
Maybe gnulib-tool/bootstrap will use some other option in the
future. Maybe they'll use --local-dir for some other reason. Maybe the
filename will change. It all feels like a little too much magic to me.
But maybe it is the cleanest way.
What do others think? Bruno, would you mind taking a look at Michael's
message? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73769
Thanks,
Karl
automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
Received: (at submit) by debbugs.gnu.org; 12 Oct 2024 11:34:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 12 07:34:16 2024
Received: from localhost ([127.0.0.1]:39247 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1szaNz-0007m5-B2
for submit <at> debbugs.gnu.org; Sat, 12 Oct 2024 07:34:16 -0400
Received: from lists.gnu.org ([209.51.188.17]:43828)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mcpratt@HIDDEN>) id 1szaNu-0007lM-6M
for submit <at> debbugs.gnu.org; Sat, 12 Oct 2024 07:34:13 -0400
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 <mcpratt@HIDDEN>) id 1szZNO-0004uy-Uw
for automake-patches@HIDDEN; Sat, 12 Oct 2024 06:29:35 -0400
Received: from mail-40134.protonmail.ch ([185.70.40.134])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <mcpratt@HIDDEN>) id 1szZNM-0007SO-Sh
for automake-patches@HIDDEN; Sat, 12 Oct 2024 06:29:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me;
s=protonmail3; t=1728728969; x=1728988169;
bh=6+ehVwaygViGajcxTR1zsmx8f31cQwES5mva8chr+Sc=;
h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
b=mojLECSPROiyNGhd1PXo8jRoo3mrBEBkkKd8FFuGq/CsQnh0r0ZiEakDDTgi/ucYD
tefz0OohTiYOnb+KBxVUodSj73PufxS2PIxb/nflO3LSQ5rOonak9q4eAatjZtgr+l
Qg2SmM7FHLvzsgUxwI5krOJlZkJXYoHcE9Oux/nRmd8c/Ds/5BTLGKnn1LMehBlJb3
QgpnZ+Axb2aXFHbwL7mPvr4n/TE4reNmdxuo4BkplrtD3h7VmMlOqCuezMDtas+RgV
uEHxOL0RMrOhBofOrh8BldOCLcQ859p74OnA+ZfyRXOFlR27cYkeJOEU4pPqaResVz
2jXy+bg7iV4Pw==
Date: Sat, 12 Oct 2024 10:29:25 +0000
To: automake-patches@HIDDEN
From: Michael Pratt <mcpratt@HIDDEN>
Subject: [PATCH] automake: distribute local gnulib directory modules
Message-ID: <20241012102824.4629-1-mcpratt@HIDDEN>
Feedback-ID: 27397442:user:proton
X-Pm-Message-ID: 3c00598741a49debd4c2ea72c9c9b066cb7d67c1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=185.70.40.134; envelope-from=mcpratt@HIDDEN;
helo=mail-40134.protonmail.ch
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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: Michael Pratt <mcpratt@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
When gnulib-tool or a bootstrap script uses the option --local-dir,
include the "modules" files in a release with DIST_COMMON. Otherwise,
these source files are present in checkouts but not in distribution.
The resulting gnulib.mk from gnulib-tool has comments
with the options used to generate it:
# Generated by gnulib-tool.
# Reproduce by:
# gnulib-tool --import --local-dir=3Dgl \
# ...
Regex match and parse this information to get any local directories.
For example, coreutils uses a local gnulib directory "gl"
so am__DIST_COMMON will include "$(top_srcdir)/gl/modules".
* bin/automake.in (read_am_file): push "modules" subdirectory of
local gnulib directories to dist_common if it exists.
Signed-off-by: Michael Pratt <mcpratt@HIDDEN>
---
bin/automake.in | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/bin/automake.in b/bin/automake.in
index a17f45236..b757a78e4 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -6520,6 +6520,16 @@ sub read_am_file
=09}
=09elsif (/$COMMENT_PATTERN/o)
=09{
+=09 # Distribute local gnulib modules.
+=09 if ($amfile =3D~ /\/gnulib\.mk/o)
+=09 {
+=09=09if ($_ =3D~ /--local-dir=3D([^\\\s]*)/o)
+=09=09{
+=09=09 push_dist_common ("\$\(top_srcdir\)/$1/modules")
+=09=09 if -d "$1/modules";
+=09=09}
+=09 }
+
=09 # Stick comments before the incoming macro or rule. Make
=09 # sure a blank line precedes the first block of comments.
=09 $spacing =3D "\n" unless $blank;
--=20
2.30.2
Michael Pratt <mcpratt@HIDDEN>:automake-patches@HIDDEN.
Full text available.automake-patches@HIDDEN:bug#73769; Package automake-patches.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.