Re: Environment variables, debian/rules and dpkg-buildpackage
> I think it's clearly mandatory to implement a hierarchy of settings:
>
> * Debian defaults
> * Local distribution overrides
> * Local package overrides
> * User settings
>
> where each overrides the previous ones.
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)
- 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)
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 ?
What would the policy change look like if we select the Makefile snippet
approach ?
> In practice, huge numbers of Debian packages already unconditionally set
> CFLAGS in debian/rules and hence override any environment variable
> settings. All those packages are going to have to be modified anyway.
> I don't see a way of meaningfully deploying this change without
> modifying most of the archive.
It would be nice to have figures here.
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.
Cheers,
--
Raphaël Hertzog
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
Reply to: