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
signature.asc
Description: signature
