Re: Environment variables, debian/rules and dpkg-buildpackage
On Fri, Mar 13 2009, Raphael Hertzog wrote:
> [ Bcced to -devel and -dpkg, discussion should happen on -policy ]
>
> Hello,
>
> we have an unfortunate situation where the practice in dpkg-buildpackage
> and the policy do not match fully.
>
> I tried to summarize the problem here:
> http://wiki.debian.org/Teams/Dpkg/DebianRules
>
> I want to resolve this problem. I see two solutions:
>
> * either we modify policy to mandate the set of environment variables that
> dpkg-buildpackage sets
>
> * or we roll-back changes to dpkg-buildpackage and design something else
> that provide the same feature in terms of distribution-wide control of
> default build options. (I ignore the DEB_VENDOR feature, it can be easily
> replaced with dpkg-vendor but the build options case is much more tricky
> to get right)
>
> In terms of efforts, the first solution is the easiest. But we aim at the
> _right_ solution so feel free to design something that makes the second
> solution viable.
There are several things I dislike about the first option.
1. I do not like that policy would turn around 15 years of convention
and suddenly outlaw $(MAKE) -f debian/rules foo. This will break
many of my packages; and I do not think that that is
justified. There are better solutions than the ones proposed.
2. As a packager, it is easy enough to over ride the setting
externally, by setting my own variables; but this makes it hard for
the end user to set the variables. I can certainly see cases where
one-size-does-not-fit all cases; so making it easy to change the
flags on a per package, per site, and a per compilation case can be,
and should be addressed.
3. dpkg-buildpackage is probably the wrong place to put this solution
in.
As a simple, off the cuff design, I can see hewing closer to the
Gentoo use flags solution, and putting in /etc/debian-build.mk makefile
snippet, which contains the default setting of the flags.
A) Project wide flags can be set by making that file part of an
essential package (perhaps dpkg).
B) The site admin can make any changes they want, like adding SELinux
or hardening flags in that file. Regular conffile handlig will allow
site admins to be aware of any project wide changes. This allows
each site to set variables for that site.
C) Each package can include that file (-include, so no errors if file
does not exist), and then override whatever variables they want in a
package specific variation.
D) The user can set the variable on the command line, which will
override the Makefile versions of the variable, for a one off per
compilation change.
The fact that dpkg-buildpackage's setting the variables is not
easily configurable, and presents to make as though it was set
on the commandline, and thus making it hard for the *USER* to set the
flag variables via env variables, is, in my opinion, a major bug.
Of course, this requires that every package rules file will need
the -include /etc/debian-build.mk at top, which makes it less than
ideal, but I am sure we can come up with a better solution.
I consider the issue of being able to set these flags on these
levels fairly important; if I have missed some use case of where one
might want to set defaults otherwise (buildd's can set arch specific
flags just like site admins can), please feel free to point it out.
manoj
--
A penny saved is a penny to squander. Ambrose Bierce
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: