Re: about dpkg-buildflags
Hi,
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
directory?)
- which can be overriden/expanded by the caller with envionment variables
(DEB_CFLAGS_OVERRIDE / DEB_CFLAGS_APPEND ?)
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 1.15.6.1.
Cheers,
--
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: