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

Re: about dpkg-buildflags


let's have the discussion on the list please. Other people can have useful
feedback on the design too.

On Fri, 19 Mar 2010, Raphael Geissert wrote:
> Yesterday I was writing a plan on how to implement what at the moment I'm 
> calling 'dpkg-buildflags' but was not sure how it was decided it should pass 
> the flags to debian/rules.
> I'm thinking about having a global (/etc/dpkg/buildflags{,.d}) config and a 
> local one (~/.dpkg-buildflags I guess). The script would take those settings 
> into consideration in addition to the env vars at the time of its execution.

There should be:
- the default value provided by dpkg
- which can be overriden/expanded system-wide with /etc/dpkg/buildflags
  (no .d, I don't think it's wise to let random packages modify the build
  flags for all packages built on the machine)
- which can be overriden/expanded by the user with ~/.config/dpkg-buildflags
  (does it make sense to use XDG-compliant config filenames for the home
- which can be overriden/expanded by the caller with envionment variables

Must we support other operations besides replacing the value and appending
more stuff to it?

> Then it comes the final question: how should the flags be passed? IIRC one of 
> the proposed solutions was to make every debian/rules include a makefile 
> snippet which would take care of calling dpkg-buildflags, but that's going to 
> take a long while before a good share of the packages actually do that 
> (there's one advantage being that dh and cdbs users don't really need to make 
> other changes).
> Another option is to make dpkg-bp call dpkg-bf and export the flags when 
> invoking debian/rules. This could "silently" be done, preserving the current 
> dpkg-bp functionality but still recommending the move to the makefile snippet. 
> The code in dpkg-bp could then be removed during squeeze+1's development 
> cycle.
> I personally would prefer the second approach not only because it preserves 
> the current functionality but because it would also allow us to start 
> enabling/disabling flags already.

dpkg-buildflags will become the official interface that packages should
use to retrieve buildflags to use. Whether or not the package use a
makefile provided by dpkg doesn't matter, it's only an optional facility
that we would provide.

For transition purpose, yes, dpkg-buildpackage should be modified to
retrieve the default flags from dpkg-buildflags but the code that exports
those variables is bound to be removed in a later release indeed.

> As for the config files, I was thinking about using some sort of 
> DEB_BUILD_OPTIONS-based approach to enable/disable groups of flags.
> For example:
> In config file something like:
> hardening => {
> 			CFLAGS => -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
> 			CXXFLAGS => -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
> 			default => enabled
> 			}
> (possibly adding some sort of CALLFLAGS that sets the same flags to both, 
> CFLAGS and CXXFLAGS, env vars. Maybe even an Architectures field to let that 
> group only be enabled on certain architectures; that would require another 
> magic flag name like 'append => yes' to make sure there can be multiple 
> definitions of the same group.)
> And then dpkg-bf would by default export those flags. Then the user could 
> disable it by prefixing the flags group (in this case 'hardening') with 'no'. 
> I.e. 'nohardening'.
> A magic group name could be added and called 'defaults' which could be 
> disabled (again, with 'nodefaults') to disable _all_ the default=>enabled 
> groups. This could be useful in debian/rules files once they start including 
> the makefile snippet by themselves to have fine-grained control over dpkg-bf.
> What do you think?

I find this difficult to understand and overengineered. Why not simply
have perl code that modifies global variables ?

In /usr/share/dpkg/buildflags or intern to dpkg-buildflags:
$CFLAGS = "-Wall -02"

In the other files the user could either use "$CFLAGS = " to override
or "$CFLAGS .= " to expand the value.

Or maybe not use perl code but something easy to parse that maps directly
to those operations:
set CFLAGS "..."
append CFLAGS "..."

> P.S. when is the next upload to unstable expected?

Not decided yet, but probably soon (next week) with

Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/

Reply to: