[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, Manoj Srivastava wrote:

>         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.

        The external file is nice in the fact that it decouples the
 installation of the essential package and the rules files; this might
 be useful for backported packages as well. In the rules file, one may
 check for the presence of the file to be included, and take different
 action based on whether it is present or not.

        Packages may continue to move over to supporting the common
 included file on their own timetable, by just not including the snippet
 until the ya re ready. And the snippet may take care of tsome of the

        So. Here is a little snippet that sets some of the flags (this
 is a demo only, I am not setting all the flags here that dpkg sets)

--8<---------------cut here---------------start------------->8---
# set CC to $(DEB_HOST_GNU_TYPE)-gcc only if a cross-build is detected
  CC = cc

# Policy 10.1 says to make this the default
CFLAGS = -Wall -g

ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
    CFLAGS += -O0
    CFLAGS += -O2

## ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
## endif

ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
  STRIP   += -s
  LDFLAGS += -s

ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
    NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
--8<---------------cut here---------------end--------------->8---


The computing field is always in need of new cliches. Alan Perlis
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: