summaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2018-09-13 11:02:32 +0200
committerThomas Haller <thaller@redhat.com>2018-09-14 08:16:57 +0200
commit0fc95d58ac19a536c1269fc8f72b0150fbc94b6b (patch)
treebe9178f9b123136022291a9cce7a1ddce0deb708 /contrib
parent2ca5eaba79c74e6f5a4f7763bb76c309fa4bf8c4 (diff)
contrib/rpm: disable --with-more-asserts for devel-builds
The NetworkManager spec file used to determine devel builds as those that have an odd minor version number. In that case, the built package would enable more-asserts. -- By the way, why is '1.13.3-dev' considered a delopment version worthy of more asserts, but a build from the development phase of the next minor release on 'nm-1-12' branch not? Note that during the development phase of Fedora (and sometimes even afterwards), we commonly package development versions from 'master'. For example '1.12.0-0.1', which is some snapshot with version number '1.11.x-dev' (or '1.12-rc1' in this case), but before the actual '1.12.0' release. It's problematic that for part of the devel phase we compile the package for the distribution with more assertions. This package is significanly different and rpmdiff and coverity give different results for them. For example, the binary size of debug packages is larger, so first rpmdiff will complain that the binary sized increased (compare to the previous version) and then later it decreases again. Likewise, coverity finds significantly different issues on a debug build. For example, it sees assertions against NULL and takes that as a hint as to whether the parameter can/shall be NULL. Keeping coverity warnings low is already high effort to sort out false positives. We should not invest time in checking debug builds with coverity, at least not as long as there are more important issues. But more importantly, the --with-more-asserts configure option governs whether nm_assert() is enabled. The only point of existance of nm_assert() -- compared to g_assert(), g_return_*() and assert() -- is that this variant is disabled by default. It's only used for checks that are really really not supposed to fail and/or which may be expensive to do. This is useful for developing and CI, but it's not right to put into the distribution. It really enables assertions that you don't want in such a scenario. Enabling them even for distribution builds defeats their purpose. If you care about an assertion to be usually/always enabled, you should use g_assert() or g_return_*() instead. What this changes, that "devel" builds in koji/brew do not have more-asserts enabled. When manually building the SRPM one still can enable it, for example via $ ./contrib/fedora/rpm/build_clean.sh -w debug Also our CI has an option to build packages with or without more-asserts (defaulting to more asserts already). (cherry picked from commit b4e2f83403e45e039fdaeb825f04324dc7220cb2)
Diffstat (limited to 'contrib')
-rw-r--r--contrib/fedora/rpm/NetworkManager.spec6
1 files changed, 0 insertions, 6 deletions
diff --git a/contrib/fedora/rpm/NetworkManager.spec b/contrib/fedora/rpm/NetworkManager.spec
index 18edf64a9..c5a2f590a 100644
--- a/contrib/fedora/rpm/NetworkManager.spec
+++ b/contrib/fedora/rpm/NetworkManager.spec
@@ -43,8 +43,6 @@
%global real_version_major %(printf '%s' '%{real_version}' | sed -n 's/^\\([1-9][0-9]*\\.[1-9][0-9]*\\)\\.[1-9][0-9]*$/\\1/p')
-%global is_devel_build %(printf '%s' '%{real_version}' | sed -n 's/^1\\.\\([0-9]*[13579]\\)\\..*/1/p')
-
###############################################################################
%bcond_without adsl
@@ -57,11 +55,7 @@
%bcond_without ppp
%bcond_without nmtui
%bcond_without regen_docs
-%if 0%{is_devel_build}
-%bcond_without debug
-%else
%bcond_with debug
-%endif
%bcond_without test
%bcond_with sanitizer
%if 0%{?fedora} > 28 || 0%{?rhel} > 7