Re: Autoconf with Debian patches

[Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Denis Ovsienko <denis () ovsienko info>
>
> Date: Fri, 6 Jan 2023 23:31:29 +0000
>
> On Fri, 6 Jan 2023 14:49:54 -0800
> Guy Harris <gharris () sonic net> wrote:
>
> > On Jan 6, 2023, at 2:24 PM, Denis Ovsienko <denis () ovsienko info>
> > wrote:
> >
> > > On Fri, 6 Jan 2023 13:25:14 -0800
> > > Guy Harris <gharris () sonic net> wrote:
> > >   
> > > > If we switch to making Debian Autoconf the new standard and keeping
> > > > the generated configure script in the repository, would that mean
> > > > that developers working from the repository would either have to
> > > > install Debian Autoconf or use "git add -p" instead of "git add"?  
> > >
> > > Yes.  Right now it is the other way around (contributors that use
> > > Debian or its derivatives have to filter their output).  So perhaps
> > > this switch would not be convenient for macOS and FreeBSD users.  
> >
> > If we go that way, we should document it when addressing developers.
>
> Yes, and it would be nice to have this documented even if we don't
> (currently the contribution guidelines do not discuss this).
>
> > Is there a place where people can download a tarball for Debian
> > autoconf and just do ./configure, make, and make install, or will
> > they have to download the Debian package and apply the patches?  If
> > the latter, we should, at minimum, give documentation on how to do
> > that - or we could just do that ourselves and have a "Debian
> > autoconf" source tarball to download.
>
> It is the latter, and a custom Autoconf seems an unreasonable
> requirement for contributing.
>
> > An alternative would be *not* to keep the generated configure script
> > in the repository (that's what Wireshark ended up doing before it
> > ceased to use autoconf/automake), and generate it as part of the
> > release-build process, which we would do on a machine on which Debian
> > autoconf was installed.
>
> Or the --runstatedir and LARGE_OFF_T bits between releases could appear
> and disappear at random until it is a release time, then the standard
> could be enforced as and if necessary.
>
> > That requires that developers have autoconf installed if they're not
> > going to be using CMake, but there are already tools they need
> > installed (a C compiler, make, Flex, Bison/Berkeley YACC, ...) so I
> > don't see that as a problem.
> >
> > It also means that configure.ac and aclocal.m4 would have to work
> > with various sufficiently-recent versions of autoconf.
>
> -- 
>     Denis Ovsienko
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers