Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On 04/01/2023 23:30, Denis Ovsienko via tcpdump-workers wrote: > As some have experienced before, attempts to regenerate the configure > script often result in two groups of unnecessary changes (runstatedir > and LARGE_OFF_T), both of which come from Debian-specific patches to > Autoconf because traditionally the configure scripts were generated > using non-Debian Autoconf. In practice this means that a regenerated > revision of a configure script almost always requires "git add -p" > instead of "git add". > > This has been discussed in some detail in [1], and my understanding is > that making Debian Autoconf the new standard should make this problem > smaller (it certainly would in my development environment). Would > anybody like to make their point for or against such a switch in one of > the next releases? > > 1: https://github.com/the-tcpdump-group/tcpslice/pull/12 I agree to use Debian Autoconf 2.69. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 4, 2023, at 2:30 PM, Denis Ovsienko via tcpdump-workers wrote: > As some have experienced before, attempts to regenerate the configure > script often result in two groups of unnecessary changes (runstatedir > and LARGE_OFF_T), both of which come from Debian-specific patches to > Autoconf because traditionally the configure scripts were generated > using non-Debian Autoconf. In practice this means that a regenerated > revision of a configure script almost always requires "git add -p" > instead of "git add". > > This has been discussed in some detail in [1], and my understanding is > that making Debian Autoconf the new standard should make this problem > smaller (it certainly would in my development environment). Would > anybody like to make their point for or against such a switch in one of > the next releases? 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"?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Fri, 6 Jan 2023 13:25:14 -0800 Guy Harris 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. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 6, 2023, at 2:24 PM, Denis Ovsienko wrote: > On Fri, 6 Jan 2023 13:25:14 -0800 > Guy Harris 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. 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. 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. 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.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Fri, 6 Jan 2023 14:49:54 -0800 Guy Harris wrote: > On Jan 6, 2023, at 2:24 PM, Denis Ovsienko > wrote: > > > On Fri, 6 Jan 2023 13:25:14 -0800 > > Guy Harris 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
Re: [tcpdump-workers] Autoconf with Debian patches
--- Begin Message --- On Jan 6, 2023, at 3:31 PM, Denis Ovsienko wrote: > It is the latter, and a custom Autoconf seems an unreasonable > requirement for contributing. Reasonable, or unreasonable? 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.) > 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? > 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.?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
