Russ Allbery wrote:
"Giacomo A. Catenazzi" <cate@debian.org> 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 program?
I see. Anyway I don't see it as configuration file, but as environment for debian/rules. 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 theoretical meaning. - 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 more interesting. 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. ciao cate