[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

On Thu, 6 Dec 2007 18:23:16 +0100, Loïc Minier <lool@dooz.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
>> package

>  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
 executable makefile. 

>  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 <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: