[buildd-tools-devel] Bug#775539: sbuild: overwrites DEB_BUILD_OPTIONS environment variable when cross-building

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2015-12-24 01:08:39)
> So I guess a sensible default would be either put this in ~/.sbuildrc:
> 
> $build_environment = %ENV;
> 
> Or to be more conservative and say:
> 
> $build_environment = {
>     'DEB_BUILD_OPTIONS' => $ENV{'DEB_BUILD_OPTIONS'}
> };

I can confirm that the latter of the above two options indeed works.

> Or to change the default of the BUILD_ENVIRONMENT config variable in Conf.pm
> from the empty hash to %ENV.
> 
> Or lastly, to change the check that you quoted above to also check
> $ENV{'DEB_BUILD_OPTIONS'} and concatenate accordingly.

Neither of the above is a sensible solution by itself. A greater pictures has
to be considered.

There are four ways for the user to influence the environment variables seen by
dpkg-buildpackage: 

 - running sbuild with the desired environment variables set
 - setting $build_environment in ~/.sbuildrc
 - setting $environment_filter in ~/.sbuildrc
 - setting $build_env_cmnd in ~/.sbuildrc to a command that sets some
   environment variables

We'll omit the last option here because it is very limited (the command cannot
have any arguments, for example).

There are two more sources for environment variables:

 - sbuild itself sets variables like APT_CONFIG and PATH
 - the chroot backend. For example schroot will set a number of SCHROOT_*
   variables

And to top it off, there are also some environment variables like
DEB_BUILD_OPTIONS where one has the choice between appending to them or just
replacing their existing value.

Now preferably sbuild should do the right thing while at the same time not
removing control from the user.

There seem to four general options:

 1) Environment variable values from the environment sbuild is run in take
    precedence over values set for the same variable in either ~/.sbuildrc or
    by sbuild itself.

 2) Environment variable values from the environment sbuild is run in are
    overwritten by values set for the same variables in either ~/.sbuildrc or
    by sbuild itself.

 3) Environment variable values from the environment sbuild is run in take
    precedence over values set for the same variable in ~/.sbuildrc but are
    overwritten by the value that sbuild conditionally itself sets.

 4) Environment variable values from the environment sbuild is run in are
    merged with values set for the same variable from ~/.sbuildrc or set by
    sbuild itself.

The sad thing is, depending on the environment variable we look at, each of the
four approaches presented above seems to have its merit:

 1) We want this for variables like CC or CXX because I want to set these on a
    per-build basis and not be influenced by my ~/.sbuildrc or whatever sbuild
    thinks is best.

 2) We want this for variables like HOME, SHELL or APT_CONFIG where the value
    set in the environment where sbuild is run in would negatively influence
    the build.

 3) We want this for variables for which having an overwritable default in
    sbuildrc is sensible but where sbuild might want to have the final say in
    certain circumstances. For example sbuild decides to only set CONFIG_SITE
    when cross building.

 4) We want this with variables like DEB_BUILD_OPTIONS though it is unclear how
    the user would then be able to "unset" certain options which are either set
    in ~/.sbuildrc or by sbuild itself (see the nocheck option set when cross
    building).

Does anybody see a sane solution that unifies all these use cases in a nice
manner? Otherwise we'll end up special casing every variable, introducing new
options and command line parameters for each (see PATH and LD_LIBRARY_PATH) and
blowing up the documentation and the code.

To start simplifying things I'd like to undo sbuild setting the nocheck
DEB_BUILD_OPTIONS. This will solve the problem of sbuild overwriting the value
of the variable and at the same time not create a situation where it is not
possible to cross build without "nocheck". At least not without having yet
another configuration variable being introduced.

What do you think?

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160126/51f8aace/attachment.sig>