> 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/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
