Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
Package: dpkg-dev
Version: 1.16..2
Hello:
I noticed that some of the options I set in DEB_BUILD_OPTIONS and
DEB_*_APPEND get overriden by DEB_*_MAINT_*.
Also I noticed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653846
seems to suggest to set
DEB_CFLAGS_MAINT_APPEND=-Os
DEB_CFLAGS_MAINT_APPEND=-O3
for when one wants to override the default optimization level and from
what I remember there are some packages that do this.
The problem is that when the user wants to do:
DEB_BUILD_OPTIONS=noopt dpkg-buildpackage -b
DEB_CFLAGS_APPEND=-O0 dpkg-buildpackage -b
or even try to cheat and do
DEB_CFLAGS_MAINT_APPEND=-O0 dpkg-buildpackage -b
the DEB_*_MAINT_* in the rules file takes priority (DEB_*_MAINT_APPEND
basically overrides anything) since it get added after the -O0 and it
needs to be changed manually in the rules file.
I would guess the DEB_BUILD_OPTIONS=noopt problem should be reported
against the package that suffer from this case but should not the user
options in
DEB_flag_* (or $XDG_CONFIG_HOME/dpkg/buildflags.conf) override the
DEB_flag_MAINT_* equivalent?
If I change BuildFlags.pm
from:
sub load_config {
my ($self) = @_;
$self-load_system_config();
$self-load_user_config();
$self-load_environment_config();
$self-load_maintainer_config();
}
to:
sub load_config {
my ($self) = @_;
$self-load_system_config();
$self-load_user_config();
$self-load_maintainer_config();
$self-load_environment_config();
}
At least the DEB_CFLAGS_APPEND=-O0 dpkg-buildpackage -b case works.
-Miguel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
Hello, On Tue, 03 Apr 2012, Miguel Colon wrote: I would guess the DEB_BUILD_OPTIONS=noopt problem should be reported against the package that suffer from this case Yes, definitely. but should not the user options in DEB_flag_* (or $XDG_CONFIG_HOME/dpkg/buildflags.conf) override the DEB_flag_MAINT_* equivalent? No. DEB_*_MAINT_* were designed to have precedence over the other variables. I agree it's unfortunate when they are used to change default values... I did not think of this when I replied to the bug report that you quoted. Package can use the STRIP + PREPEND commands to set defaults but it's not a really nice interface either. I'm not sure what the proper approach would be. On the other hand, I'm not entirely convinced that it's important to let the user have the last word in cases where maintainers have opted for a specific optimization level: - building with -Os is typically made for udeb and I don't see a compelling reason to have the possibility to change the maintainer choice via the environment variable - building with -O3 is often picked as a work-around when -O2 doesn't give the expected result, why would you want to pick another optimization level? if you want -O0, then it's the noopt option that you should be using Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
I'm not sure what the proper approach would be. On the other hand, I'm not entirely convinced that it's important to let the user have the last word in cases where maintainers have opted for a specific optimization level: - building with -Os is typically made for udeb and I don't see a compelling reason to have the possibility to change the maintainer choice via the environment variable - building with -O3 is often picked as a work-around when -O2 doesn't give the expected result, why would you want to pick another optimization level? if you want -O0, then it's the noopt option that you should be using Well any flag not only optimization levels are affected but -OX is probably the most common case. Also some packages do export DEB_CFLAGS_MAINT_SET=$(dpkg-buildflags --get CFLAGS) which makes the -02 and the other flags permanent. Anyway I just wanted to be able to be sure that the flags I wanted to use for testing or building a local package for my system where actually used without having to manually check each source to see if there is a DEB_*_MAINT_* now or in the future that disables those flags. I think the user should have the last say when building locally since the user is willingly trying to use a flag locally but the current method just adds the annoyance of either having to modify the rules file, modify the BuildFlags.pm file or creating a gcc/g++ wrapper. -Miguel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
On Tue, 03 Apr 2012, Miguel Colon wrote: Well any flag not only optimization levels are affected but -OX is probably the most common case. Any flag that allow overriding a previous value of the same flag and that maintainers are likely to change... wich doesn't make many. Also some packages do export DEB_CFLAGS_MAINT_SET=$(dpkg-buildflags --get CFLAGS) which makes the -02 and the other flags permanent. This is a pretty stupid thing to do. What package is doing this? Is there a reason given? In any case, feel free to open a bug against the affected packages. Anyway I just wanted to be able to be sure that the flags I wanted to use for testing or building a local package for my system where actually used without having to manually check each source to see if there is a DEB_*_MAINT_* now or in the future that disables those flags. I think the user should have the last say when building locally since the user is willingly trying to use a flag locally but the current method just adds the annoyance of either having to modify the rules file, modify the BuildFlags.pm file or creating a gcc/g++ wrapper. Well, I took the conservative approach in letting maintainers have the possibility to override/strip flags that are known to break the package. That way even if the user puts some dangerous flags in his default configuration, we maximize the set of packages that will continue to build. But obviously if you put yourself not as a user who needs the resulting package, but as a developer who is doing tests to see how many packages break with a given flag, then this decision might annoy you. We can invert the order between the maintainer environment variable and the user environment variable but I'd like the input of others because I can't really make up my mind on whether it's right and a realy useful thing to do. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
Well any flag not only optimization levels are affected but -OX is probably the most common case. Any flag that allow overriding a previous value of the same flag and that maintainers are likely to change... wich doesn't make many. True, I was also thinking about the silly case when someone used DEB_*_MAINT_SET which I would guess break noopt and disable any user flag. Also some packages do export DEB_CFLAGS_MAINT_SET=$(dpkg-buildflags --get CFLAGS) which makes the -02 and the other flags permanent. This is a pretty stupid thing to do. What package is doing this? Is there a reason given? In any case, feel free to open a bug against the affected packages. Oh I was trying to search how many packages currently use DEB_*_MAINT_* options and found that one with a web search. I did not try an exhaustive search (should not be that many anyway) since it was 5am and this is more of a wishlist type of change since from the original email I gathered that this behavior was intentional by dpkg. The package that did this was http://packages.debian.org/sid/crash from what I remember. I will open the bug when I get home in a couple of hours if there is none. But obviously if you put yourself not as a user who needs the resulting package, but as a developer who is doing tests to see how many packages break with a given flag, then this decision might annoy you. True, I noticed this testing some packages with gcc-4.7 and custom flags with a custom pbuilder script. I was trying to remove the ugly gcc-wrapper that I used to insert/remove flags and try a cleaner approach and then found this. We can invert the order between the maintainer environment variable and the user environment variable but I'd like the input of others because I can't really make up my mind on whether it's right and a realy useful thing to do. This sounds reasonable, thanks!. Cheers, Miguel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
