On Fri, 2006-03-24 at 22:07 +0100, Julien Danjou wrote: > Finally, I solved it this way: > > diff -u tar-1.14/debian/rules tar-1.14/debian/rules > --- tar-1.14/debian/rules > +++ tar-1.14/debian/rules > @@ -16,7 +16,7 @@ > build-stamp: > dh_testdir > > - $(MAKE) > + RSH="/usr/bin/rsh" CFLAGS="-O2 -g -Wall" $(MAKE) > (cd tests ; $(MAKE) check-TESTS) > > touch build-stamp
It certainly seems to make sense to provide the same environment to make that we're using for configure, so I'll add this to my CVS for the next upload to unstable. If that is sufficient to ensure a clean build of a 1.14-2.2 version on all architectures affected by the bug in question, I have no problem with that change being included for the next stable update. However, I don't immediately understand why the auto* tools are being invoked by make during this build? Reviewing the tar changelog, I made explicit reference for 1.14-1 that autoconf and automake build dependencies were elminated. Nothing I changed for 1.14-2 should have affected that, and it's not obvious that anything in the diff between -2 and -2.1 should have affected that either. However, I left in place the code in the debian/rules file that updates config.sub and config.guess in the 'clean' target *if* autotools-dev is installed. So, I wonder if the underlying problem is that those files are being updated and somehow triggering this behavior? Goswin indicates in his reply to this message that we should "touch the files in the right order", but I'm not sure what that refers to in this case? For 1.15.1-4, I re-introduced a dependency on autoconf in response to #354194. In hindsight, that may not have been the right thing to do... and even if it was the right thing to do, I'm not sure it was really sufficient. It would seem desireable to not run the auto* tools on every build if we don't need to, yet if we're going to then there should probably be an autotools-dev build dependency, etc? For whatever reason, I'm having a hard time thinking clearly about this today, and so advice and/or suggested patches for the version currently in unstable to do "the right thing" in the future would be appreciated. Regards, Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
