Bruno Haible via Bug reports for the GNU Internet utilities <bug-inetutils@gnu.org> writes:
> Simon Josefsson wrote: >> My view is changing towards seeing gnulib like just any other build-time >> dependency. We are using versioned build dependencies of >> Trisquel/Guix/Debian/RHEL and autoconf, automake, help2man, etc in CI/CD >> because we want to test those versions. We aren't using bleeding edge >> autoconf, automake, etc in CI/CD when building inetutils. So using a >> specific gnulib commit seems to match how we treat all other build >> dependencies. > > That's a valid way to see things, yes. Some time ago, Tim Rühsen configured > the Gnulib CI to use the bleeding edge Debian. But I don't want to spend > time debugging Debian, therefore I picked a fixed Debian release instead. Yes, I've had this challenge too and after going back and forth between use of stable and testing OS releases a couple of time, I realized that both have their use. I now add jobs for both pinned version releases (because that's what users tends to use and what I want to check works) and testing/rolling releases (to catch early regressions before they hit released versions). Then during times where Debian testing is completely broken, I can just ignore the failing jobs, and still have passing jobs that give confidence in any patches. >> However I do agree with you about the utility of ALSO building inetutils >> with bleeding edge gnulib. > > Implemented through > https://github.com/gnu-inetutils/ci-check/commit/b68ebfb39d74809422cf8452aefc7309f0b6940e > Let's see how it works... Nice! I hope to add a use-latest-gnulib CI job to gitlab too. For the remote possibility that gnulib master is known buggy for a some extended set of time, having the inetutils CI not test intended gnulib commit depending on which day it is running may be a bit annoying when fixing things and desiring a predictable CI. But we'll see. There are already similar issues around midnight, if you prepare a 'make release' tarball at 23:59 in one CI/CD job and another 'make release' tarball at 00:01 in another CI/CD job, the tarballs could end up being different due to embedded build-time dates. I think I have fixed most glaring examples of this in some projects, and it was some months ago it last happened. The take away is that build time should not matter: when there is a desire to look at timestamps, derive it from the latest git commit time instead. /Simon
signature.asc
Description: PGP signature
