Manoj Srivastava wrote:
On Sun, May 10 2009, Steve Langasek wrote:On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:Guillem pointed out one problem: Either you do it via a make include (which you have issues with), or you stop supporting calling debian/rules directly (inconvenient, probably prone to break things)I thought it was generally recognized that it's a Bad Idea to implement config files using your interpreter's 'include' functionality, but that's basically what we have here.I don't agree that "dpkg-buildpackage sets additional environment variables to implement a distro/site policy for builds" implies "calling debian/rules directly is unsupported". Or maybe I've misunderstood, and there are Debian developers who are building official packages for *upload* by calling debian/rules by hand, and that's what people are concerned about preserving while still getting the benefits of these distro build flags?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. Note: it is also used to do "make clean" before *any* build, because the non traced dependencies. E.g. on old time, some kernel configurations needed a "make clean". I don't think I want to remember when I need to run "make clean", so any changes on compiler, on configuration or other heavy changes I run "make clean". I think for the same reason people (but people very deep in debian packaging) will use dpkg-buildpackage: not the optimal way, but it is safer, and with less "surprises". A new point, still neglected on this thread: there are other nasty cases: as we saw in an other thread on debian-policy, the current locale changes the way wide-characters (and wide strings) are encoded in binaries (UTF-16 if current charset in current locale could be encoded in 16-bit; UTF-32 on other cases, and fortunately when no charset is specified on current locale, thus also on "C" locale). Wide characters are not common, but they are specified not only in POSIX but also in standard C (also in C89/C90 version IIRC). I don't see a good way that: - developers will do the right things (how many of you doesn know such strangeness?) [ add a flag to CFLAG in every debian/rules is IMHO not the right thing ] - it is documented (e.g. on logs), actually we need to parse binaries to find what type of encoding did the original uploader (not so complex because we have only currently two encoding, but anyway...] - security team and MNU doesn't break package because of nasty interaction because of different locale. other than using dpkg-buildpackage (and letting dpkg-buildpackage to set this (and probably other nearly-unknow paramenters) ciao cate