Manoj Srivastava <sriva...@debian.org> writes: > Also, any upstream Makefile that sets CFLAGS (don't most ones > that use automake do that?) will also be not affected, unless even more > hackery is done. At this point, what dpkg does to these variables not > enough to justify any such effort.
Most packages that use Automake also use Autoconf, and Autoconf picks up CFLAGS from the environment at the time configure is run, so most Automake packages would pick up an environmental default. However, I expect many packages are shielded at present by use of the default Policy-recommended explicit setting of CFLAGS. I know nearly all of mine (that care about CFLAGS at all) are. The main exception are Perl modules, for which I've mostly switched to debhelper v7 rule minimization. When this change was originally made in dpkg-buildpackage, it broke several packages that didn't have this shield. I'm not sure if there was a common way in which those packages are fixed or how many of them went back to setting CFLAGS explicitly. > On Wed, Mar 18 2009, Raphael Hertzog wrote: >> While I agree that the distinction is blurred because in the rules files >> you don't know where the env var comes from, I don't agree that it's a >> deficiency. > A missing feature is a deficiency. How critical a deficiency it > is is a matter of opinion, and we apparently differ. And for what it's worth, I agree with Manoj here. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
