[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

        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.

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: