Re: Environment variables, debian/rules and dpkg-buildpackage
Russ Allbery wrote:
"Giacomo A. Catenazzi" <email@example.com> writes:
Manoj Srivastava wrote:
The only builds Debian supports are not just the buildd ones. As
members of the free software community, we should also cater to end
users building, tweaking, and rebuilding our software.
You are a very special case: a developer since very long time, with a
enormous knowledge of debian policy (and dpkg internal). But I really
think that most people outside DD use dpkg-buildpackage because it is
the easier way (without need to remember a lot of details). I think
also that most of DDs use dpkg-buildpackage.
The number of people using different methods is fairly irrelevant to
Manoj's point. The question is more fundamental: are packages built by
a makefile that we call debian/rules, or are they built by the program
dpkg-buildpackage using debian/rules as a configuration file for that
Anyway I don't see it as configuration file, but as environment for
Note: currently we use fakeroot in order to setup other things
of "environment". It is not mandatory (we can build deb as superuser),
but also dpkg-buildpackage will not be mandatory (if user set
some environment variable).
Could maintainer do a sensible choice of CFLAGS? I don't think so.
The flags are too much dependent on architecture then the
- Support of some flags on some architecture is broken
(according to documentation)
- optimization is not safe on some architectures (broken
compiler) or it worse the code (broken default choices)
- debug symbol format changes in different architectures:
we need to use -g, -ggdb or what?
For these reasons I see CFLAGS more as an architectural choice
than a maintainer choice. But I'm not an expert on the field,
and I've no packages on core Debian, where flags could be
And in the thread, it seems that there are such cases. I'm
currious to see what are such cases (maintainer MUST override
flags) and the reason.
In every case, I think the .dsc should include some build
information, to block earlier some build errors
(e.g. include with custom setting, or dpkg-buildpackage
non Debian-standard settings). We will do errors, so we need
also a way to find out such errors.