On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote: > On Sun, 10 May 2009, Steve Langasek wrote: > > I'm really surprised to see this approach getting traction. To me, this > > seems like a significant, unprecedented departure from the kinds of > > interfaces we've mandated in Policy in the past (i.e., environment > > variables, executables and command-line options). While one build helper or > > another may mandate Makefile includes, there's never been anything of the > > sort in Policy, and I don't think it's good to add such a thing now. I > > thought it was generally recognized that it's a Bad Idea to implement config > > files using your interpreter's 'include' functionality, but that's basically > > what we have here.
I have sympathy for Steve viewpoint however it lacks an alternative proposal. However I cannot only strongly disagree with Raphael argument below: > Another negative aspect of the include approach is the lack of > tracability. Right now when the user overrides a build flag it appears > in the build log since dpkg-buildpackage prints it out in the log: > dpkg-buildpackage: use CFLAGS from environment: -O3 -Wall > > With the include approach, we lack this feature and bad/broken local > overrides can't be detected if we only have the build log at hand. There is nothing that prevents a future dpkg-buildpackage to cat to stdout the relevant files at startup so that they appear in the buildlog. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
