Package: dpkg
Version: 1.15.0
Since version 1.15.0 version of dpkg, dpkg-buildpackage sets default
compiler flags.
This breaks some packages that used to build fine with older versions of
dpkg. The issue is basically that extra flags get expanded in the
compiler lines, causing the compilation to fail.
The old version set nothing, so there was no environment variable such
as LDFLAGS present. With new dpkg, it's always present, although empty.
This may cause problems in the submakes.
Here's a trivial example of the problem:
% env | grep FOO
% make
echo topmake foo: 'bar'
topmake foo: bar
make -C sub
make[1]: Entering directory `/tmp/jhakala/make/sub'
echo submake foo: ''
submake foo:
make[1]: Leaving directory `/tmp/jhakala/make/sub'
% export FOO=
% make
echo topmake foo: 'bar'
topmake foo: bar
make -C sub
make[1]: Entering directory `/tmp/jhakala/make/sub'
echo submake foo: 'bar'
submake foo: bar
make[1]: Leaving directory `/tmp/jhakala/make/sub'
So, in a case like above, if any compiler flag is set as empty as
default, it will introduce any compiler flags appearing in a single
makefile in their submakes.
The change seems pretty fundamental shift in how dpkg-buildpackage
works, right? I was able to catch this as the expanded values broke my
compilation but how many packages are there that get extra flags due to
this but just don't happen to choke on them?
Of course, this can be labeled just as bad packaging (or in the case of
the upstream software - bad design), but I feel somewhat uncomfortable
about this behavioral change as it potentially gives unexpected,
seemingly random results.
Here's the dump of the makefiles I used:
% cat Makefile
FOO = bar
default:
echo topmake foo: '$(FOO)'
make -C sub
% cat sub/Makefile
default:
echo submake foo: '$(FOO)'
Regards,
Jussi
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
