Re: about dpkg-buildflags

[Raphael Geissert <geissert@debian.org>]

Hi,

Sorry for the late response.

Raphael Hertzog wrote:

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

Okay.

> 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)

The idea behind the .d directory was to allow package maintainers to add 
more settings groups.
Say you have a python, perl, php or whatever module/xs/extension that can be 
affected by build flags. The main -dev package of the given scripting 
language could then provide a settings group that could be used, for 
example, to enable certain non-standard features, or even disable them.
Settings provided inside the .d directory would then not be enabled by 
default.

This therefore allows two different kinds of uses: 1) allowing a centralized 
place for custom settings that could be used by a common group of packages, 
and 2) just like the previous feature but user-controlled.

For example, in the case of PHP we build the packages with LFS support which 
breaks the ABI. For this very case there are two possible uses: 
1) one is to make sure all packages building extensions call dpkg-buildflags 
php-lfs to get the LFS flags which were used by the main package at build 
time.
2) LFS (and the ABI breakage) could be disabled when building the main 
packages via a standard interface (dpkg-buildflags lfs) and the setting 
could be reflected on the other packages when they call php-lfs.

What do you and the other readers think about that use case?

> - 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?)

Not sure. Only very few programs actually use the .config directory.

> - which can be overriden/expanded by the caller with envionment variables
>   (DEB_CFLAGS_OVERRIDE / DEB_CFLAGS_APPEND ?)

I think it would be better for everybody's sake if this is done via command 
arguments instead of (ab)using env vars. What would those operations do 
anyway? The caller should just enable or disable a set of groups if it needs 
to do anything else more than just calling dpkg-buildflags.

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

I was thinking it could even be extended beyond build flags (in the strict 
sense of CFLAGS/CXXFLAGS, etc): configure flags could also be supported.

>> 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 "..."
> 

The idea was to make it language-independent so that other tools can easily 
parse them. Having defaults => true/false support would enable some of the 
features I mentioned above. Architecture-dependent configurations would for 
example allow the whole hardening-wrapper/includes logic to be moved as 
dpkg-bf configs (some archs don't correctly support certain features, others 
produce bogus code, etc).

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net