On Fri, 13 Mar 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.
Packages are not suddenly broken, no. The fact the we require that some
environment variables are set to specific values when we call debian/rules
won't break packages.
(It did break some packages when dpkg-buildpackage started setting those
variables (in the lenny cycle) but they have all been fixed now.)
Note also that all buildd use dpkg-buildpackage and a majority of DD
also use dpkg-buildpackage, directly or indirectly with debuild or
something similar.
> 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.
Yes.
> 3. dpkg-buildpackage is probably the wrong place to put this solution
> in.
Why?
> 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.
This is wrong. dpkg-buildpackage preserves the value set by the user if
any. It simply sets default values to all those environment variables if
they have none.
Did you care to check before doing such a bold assertion ?
For reference, here's the code that sets the build options:
----
my $default_flags = defined $build_opts->{noopt} ? "-g -O0" : "-g -O2";
my %flags = ( CPPFLAGS => '',
CFLAGS => $default_flags,
CXXFLAGS => $default_flags,
FFLAGS => $default_flags,
LDFLAGS => '',
);
foreach my $flag (keys %flags) {
if ($ENV{$flag}) {
printf(_g("%s: use %s from environment: %s\n"), $progname,
$flag, $ENV{$flag});
} else {
$ENV{$flag} = $flags{$flag};
printf(_g("%s: set %s to default value: %s\n"), $progname,
$flag, $ENV{$flag});
}
if ($ENV{"${flag}_APPEND"}) {
$ENV{$flag} .= " ".$ENV{"${flag}_APPEND"};
}
}
----
> 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.
We probably don't want to directly include a conffile in our rules files.
I will rather opt for a file in /usr/share/dpkg/ that would try to include a
file from /etc/dpkg to keep the possibility for the local admin to override
default build settings.
> 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.
Like what? It is the biggest disadvantage compared to the other solution
and the main reason that I still prefer the other approach.
> 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 site-wide configuration of default flags is currently lacking
in dpkg-buildpackage but I can add that support if needed. We only need
to add a configuration file for this.
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
