GNU bug report logs - #73769
[PATCH] automake: distribute local gnulib directory modules

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73769 in the body.
You can then email your comments to 73769 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Pratt <mcpratt <at> pm.me>
To: automake-patches <at> gnu.org
Cc: Michael Pratt <mcpratt <at> pm.me>
Subject: [PATCH] automake: distribute local gnulib directory modules
Date: Sat, 12 Oct 2024 10:29:25 +0000

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=gl \
  # ...

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 <at> pm.me>
---
 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
 	}
 	elsif (/$COMMENT_PATTERN/o)
 	{
+	    # Distribute local gnulib modules.
+	    if ($amfile =~ /\/gnulib\.mk/o)
+	    {
+		if ($_ =~ /--local-dir=([^\\\s]*)/o)
+		{
+		    push_dist_common ("\$\(top_srcdir\)/$1/modules")
+		      if -d "$1/modules";
+		}
+	    }
+
 	    # Stick comments before the incoming macro or rule.  Make
 	    # sure a blank line precedes the first block of comments.
 	    $spacing = "\n" unless $blank;
-- 
2.30.2

Message #8 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: mcpratt <at> pm.me
Cc: bruno <at> clisp.org, 73769 <at> debbugs.gnu.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Sat, 12 Oct 2024 14:57:17 -0600

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

Message #11 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: mcpratt <at> pm.me, bruno <at> clisp.org, 73769 <at> debbugs.gnu.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Sat, 12 Oct 2024 15:12:59 -0700

Hi Karl,

Karl Berry <karl <at> freefriends.org> 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

Message #14 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: mcpratt <at> pm.me, Karl Berry <karl <at> freefriends.org>
Cc: 73769 <at> debbugs.gnu.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Sun, 13 Oct 2024 00:51:14 +0200

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

Message #17 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Michael Pratt <mcpratt <at> pm.me>
To: "bruno <at> clisp.org" <bruno <at> clisp.org>
Cc: "collin.funk1 <at> gmail.com" <collin.funk1 <at> gmail.com>,
 Pádraig Brady <P <at> draigBrady.com>,
 "73769 <at> debbugs.gnu.org" <73769 <at> debbugs.gnu.org>,
 "karl <at> freefriends.org" <karl <at> freefriends.org>
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Mon, 14 Oct 2024 06:40:37 +0000

Hi all, thanks for the detailed response,

I had been discussing this with Pádraig, 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 maintainers.
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 build 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 <at> gmail.com> 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="--tests-base=gnulib-tests --with-tests --symlink\
> --makefile-name=gnulib.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 <at> clisp.org> wrote:

>
> 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=([^\\\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 modifications made
for "personal use" or testing, etc. before attempting to make a distribution.

However, if including an entire subdirectory is not acceptable, this too can 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 source"
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

Message #20 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Michael Pratt <mcpratt <at> pm.me>
Cc: collin.funk1 <at> gmail.com, Pádraig Brady <P <at> draigbrady.com>,
 73769 <at> debbugs.gnu.org, karl <at> freefriends.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Mon, 14 Oct 2024 11:47:21 +0200

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

Message #23 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: mcpratt <at> pm.me
Cc: P <at> draigBrady.com, bruno <at> clisp.org, 73769 <at> debbugs.gnu.org,
 collin.funk1 <at> gmail.com
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Mon, 14 Oct 2024 13:54:40 -0600

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.

Message #26 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: mcpratt <at> pm.me, Karl Berry <karl <at> freefriends.org>
Cc: P <at> draigbrady.com, 73769 <at> debbugs.gnu.org, collin.funk1 <at> gmail.com
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Mon, 14 Oct 2024 22:06:30 +0200

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

Message #29 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Michael Pratt <mcpratt <at> pm.me>
To: Bruno Haible <bruno <at> clisp.org>
Cc: collin.funk1 <at> gmail.com, Pádraig Brady <P <at> draigbrady.com>,
 73769 <at> debbugs.gnu.org, karl <at> freefriends.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Tue, 15 Oct 2024 14:43:35 +0000

Hi again,

On Monday, October 14th, 2024 at 05:47, Bruno Haible <bruno <at> clisp.org> wrote:

> 
> 
> 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,

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 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?
If there were any instructions on who I should CC, and when, I never saw them.


> 
> 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 first.
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

Message #32 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Michael Pratt <mcpratt <at> pm.me>, 73769 <at> debbugs.gnu.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Tue, 15 Oct 2024 12:03:58 -0400

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

Message #35 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Michael Pratt <mcpratt <at> pm.me>
Cc: collin.funk1 <at> gmail.com, Pádraig Brady <P <at> draigbrady.com>,
 73769 <at> debbugs.gnu.org, karl <at> freefriends.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Tue, 15 Oct 2024 22:22:59 +0200

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

Message #38 received at 73769 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: mcpratt <at> pm.me
Cc: 73769 <at> debbugs.gnu.org
Subject: Re: [bug#73769] [PATCH] automake: distribute local gnulib directory
 modules
Date: Sun, 23 Feb 2025 14:34:44 -0700

I think there is nothing to do here at this time, so closing.
Feel free to reopen (or open a new issue) if the idea progresses.
Thanks,
karl

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.