On Thu, 26 Feb 2009 11:39:36 +0000, Richard wrote: > On Thu, Feb 26, 2009 at 10:47:07AM +0100, Michael Schwendt wrote: > > Patches? ... Patches created by regenerating modified autotools > > input files? > > > > That won't be different from running autotools at build-time. With one > > exception: you get a chance to examine the patch and verify it and the > > results it produces -- you can't do that with unattended rebuilds in a > > build system where the autotools versions may change any time and cause > > unexpected side-effects. > > In some theoretical world perhaps. What makes you think so? My opinion is based on experience. > In reality though - the patches are full of unintended changes Correct. Hundreds if not thousands of changed lines in shell script or m4 code. > (eg. if there is a change of autoconf), and even if you get a minimal > patch, it's still a patch to some giant shell script which is very > hard to verify. You're not supposed to verify a thousand lines of shell code. It sufficient if you verify (1) which files get regenerated and (2) that the build log and the build results are as expected. > Also in the real world, builds don't tend to break > because of autotools changes, It's the contrary. They have caused breakage so often, it lead to inclusion of multiple releases of various autotools in this Linux distribution. According to your theory, one could simply have run/used the latest release of the autotools. > and if they do, they're much simpler to fix. That is not what has happened. Access to private albeit not hidden variables and cache variables, for example, has caused lots of silent breakage. And that's just one example. We're not talking about trivial fixes where a function/macro name has changed and is rejected when re-running the latest autotools. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
