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:
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.
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 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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
