Re: Environment variables, debian/rules and dpkg-buildpackage
On Sun, Mar 15, 2009 at 05:33:31PM +0100, Raphael Hertzog wrote:
> On Fri, 13 Mar 2009, Manoj Srivastava wrote:
> > There are several things I dislike about the first option.
> > 1. I do not like that policy would turn around 15 years of convention
> > and suddenly outlaw $(MAKE) -f debian/rules foo. This will break
> > many of my packages; and I do not think that that is
> > justified. There are better solutions than the ones proposed.
> Packages are not suddenly broken, no. The fact the we require that some
> environment variables are set to specific values when we call debian/rules
> won't break packages.
> (It did break some packages when dpkg-buildpackage started setting those
> variables (in the lenny cycle) but they have all been fixed now.)
You are conflating breakage that were reported with breakage that appeared
but were not reported.
There is no documented semantic for CFLAGS et. al. in Debian policy. While
some Makefile handle it in a certain way, this is not mandatory in
any way. For example some configure scripts append options to CFLAGS while
other will not change it if it is defined. For example a package might be miscompiled if -fno-strict-aliasing is not given to gcc but a setting CFLAGS might
cause this setting not to be added by configure, leading to a subtly broken
package, that will not be detected at build time.
Changing CFLAGS behind the back of the maintainers is potentially changing
how the package is build in a undefined way. A package built in such way should
be assumed broken.
Imagine a large red swirl here.