--- Begin Message ---
On Fri, 6 Jan 2023 17:13:20 -0800
Guy Harris <ghar...@sonic.net> wrote:
> On Jan 6, 2023, at 3:31 PM, Denis Ovsienko <de...@ovsienko.info>
> wrote:
>
> > It is the latter, and a custom Autoconf seems an unreasonable
> > requirement for contributing.
>
> Reasonable, or unreasonable?
Unreasonable, if it is more complicated than installing an Autoconf
package using the package manager of the OS.
> Whatever version is chosen as the standard autoconf, if the goal is
> to have the version of the configure script in the repository always
> be generated by the standard autoconf, some users will have to build
> and install that version if they will be changing the configure
> script, and, for other contributions, they'll either have to build or
> install that version or they will have to take care not to check in
> the configure script if they haven't changed configure.ac or
> aclocal.m4.
>
> (By the way, have other Linux distributions applied the same changes
> that Debian and its derivatives have? If not, then users of those
> distributions would be in the same situation as macOS and FreeBSD
> users.)
I do not remember to what extent these patches have propagated beyond
Debian and Ubuntu. Maybe somebody else has other distributions ready to
check?
> > Or the --runstatedir and LARGE_OFF_T bits between releases could
> > appear and disappear at random
>
> Meaning we let users check in the configure script in whatever form
> it exists on their machine?
Yes. The obvious drawbacks of that would be lowering signal-to-noise
ratio in the diffs and potentially making subsequent git-cherry-pick
more likely to fail due to merge conflicts.
> > until it is a release time, then the standard
> > could be enforced as and if necessary.
>
> I.e., part of the process of making a release would be regenerating
> the configuration file using Debian autoconf and checking in the
> regenerated version.?
Yes. This bit looks relatively simple.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
