Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery <rra@debian.org>]

Raphael Hertzog <hertzog@debian.org> writes:

> I think we all mostly agree on that. I see only two remarks:
> - the package can either fully override the default settings or
>   filter the provided build options: i.e. add/remove/replace build
>   options. (and I think that the "filter" option should be the recommended
>   approach)

Yes.

> - the user should also be able to provide a default build option that the
>   package can override in case the user wants to trust the
>   maintainer's opinion on what build options are sane or not for this
>   specific package (it might allow him to have a better success rate if you
>   want to recompile lots of packages with some options that are known to
>   not work in some cases)

I don't think this is particularly important at a level of granularity
less than the system configuration level (in other words, having the user
do this by changing a conffile would be fine with me).  I base this on my
experience as a user overriding compilation flags long before I'd ever
used Linux, where if need be I'll just cut and paste what the package
currently uses and change it slightly when building regular packages.
This is pretty much par for the course for overriding configuration like
that.

> Do we want that hierarchy set in stone in policy or do we simply want to
> define how the rules file is supposed to retrieve the relevant build
> options ?

I think we should say something about the hierarchy of options in Policy
at least as non-normative text as an explanation for what on earth we're
trying to accomplish, so that ten years from now we can figure out what we
were thinking.

> What would the policy change look like if we select the Makefile snippet
> approach ?

Roughly:

All packages should add:

    include /etc/dpkg-dev/build-options.mk

to their debian/rules file.  This file will set the following options:

    CFLAGS
    LDFLAGS
    ...

Packages should use those settings by default (with appropriate changes or
propagation into other variables as needed by the build system of the
package -- insert explanation of what each of them means here), but the
package may override or change those settings if they're not appropriate
for this particular package.

Users when building a package may override both the defaults and
debian/rules by setting the appropriate variable on the make command line
with, for example:

    make -f debian/rules CFLAGS=blah

Not in Policy: dpkg-buildpackage could certainly have a useful option for
doing the last, and I think that would be a worthwhile feature.

> It would be nice to have figures here.

I don't have time to write the code myself, but it should be fairly
trivial to find most packages that set CFLAGS explicitly by looking at the
rules file in the Lintian lab on gluck.  You'll miss more complex makefile
include systems, but you'll get most of the cases.

> Note that we have packages switching to debhelper 7 rules files as
> simple as /usr/share/doc/debhelper/examples/rules.tiny so the number of
> packages explicitely setting CFLAGS might drop.

Yes, agreed.

Note that all CDBS packages can easily switch to whatever we want,
including makefile snippets, with a rev to CDBS.  debhelper 7 with minimal
rules will probably need to add the include file directly, since debhelper
isn't in as good of a position to force the makefile inclusion.  (There
are ways in which it could, but they all seem very ugly to me.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>