Re: Environment variables, debian/rules and dpkg-buildpackage
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> And you are missing the point that making people type stuff on
>> the command line for site specific stuff looses out to being able to
>> edit a conffile instead.
> Who said the command line was for site-specific stuff?
> In my proposition the hierarchy could be something like this:
> - distribution default (encoded in dpkg-buildpackage or in a
> /etc/dpkg/origins/ file)
The latter is better, since it does not force people to iuse
dpkg, and does not force blended distributions and derivatives to
modify dpkg every time they want a change.
> - site-specific (/etc/dpkg/dpkg-buildpackage.conf)
> - package specific (inside debian/rules)
> - user specific (command line options)
> In my opinion, the origin of the variable is not important, the only
> important part is to specifiy in policy how the value is communicated to
> the rules file.
I ahd not read this changed proposal until now. This is close
enough to what I was saying to be workable -- as long as the project
defaults are in a file, and not hard coded into a script.
The only other caveat I would put in is implementation details,
with my Make hat on: Use the := and = variants in make to set variables
that help differentiate the policies that the variables define;
default_foo := PROJECT_VALUE # set in /etc/dpkg/origins
-include /etc/dpkg/default.mk # set in /etc/buildpackage.mk
site_foo := SITE_VALUE # set in /etc/buildpackage.mk
ifneq (,$strip($(site_foo))) # also set in /etc/buildpackage.mk
foo = $(site_foo)
foo = $(default_foo)
# in debian/rules
# Set foo here, if necessary
With such a template, we can override either the default, or
site, policy, either in the debian/rules, or on the command line.
I think we are close.
Death is nature's way of saying `Howdy'.
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C