Re: Proposalto introduce compiler options passed from dpkg-buildpackage
On Thu, 6 Dec 2007 18:23:16 +0100, Loïc Minier <firstname.lastname@example.org> said:
> On Thu, Dec 06, 2007, Manoj Srivastava wrote:
>> a) Adds no practical value
> It's about rejecting a change to policy; I don't see why it should
> add practical value.
The change was made in 2001. That is nearly 7 years ago. It
represents current practice. Get over it.
>> b) does not represent current practice
>> c) not implementing the proposal is not a technical hindrance to any
> This is the same point. Just for the record, there's a small set of
> packages not based on a Makefile for debian/rules.
I know. I saw the list Russ posted. Not enough to change the
rule. This is a policy directive which has been in place for over 6
years. The packages need to be fixed.
>> d) stands in the way of technical proposals like passing information
>> to the build system on the command line
>> e) prevents people from relying on make semantics for builds.
> The two above points are the same argument. The only proposal I know
> it stands on the way of is the one to list implemented targets with a
> special make invocation which seemed flaky anyway.
What seems flaky to you is unimportant, if indeed it works.
>> The only reason for the bug report seems to be
>> a) because we can
>> b) aesthetics
>> c) profit???
> Not constraining the interface if we don't need to? There's a huge
> difference in possibilities between "any script" and "a Makefile".
I do not agree that there is no need to so constrain it. I have
made the argumen in #88111; please read it. And the current brouhahah
is another reason why the make directive could be used to pass
information to the build process since we do know ./debian/rules is an
> Yes, we can do it in other ways, such as defining which flags or env
> vars have to be honored, or which files have to be read.
Right. We can re-invent the wheel on our own, in a classic
example of NIH, for absolutely no reason -- apart from not liking a
solution that is already in place.
Not a great idea.
"Pull the trigger and you're garbage." Lady Blue
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C