With https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
we try to remove ldconfig scriptlets, but it would make every package
look horrible with all those conditionals. So let's just wrap ldconfig
scriptlets into macro so it doesn't look that horrible and error-prone.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
If there are unpackaged symlinks, build will fail with unpackaged files.
People can %undefine __brp_ldconfig if they need to and they should make
sure that they call ldconfig themselves.
Right now, script doesn't guide packagers what to do, but it's not
prerequisite.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Add a separate macro for each brp we have, using standard naming
convention and conditionalize the usage in %__os_install_post.
Voilà, we have a standard way to disable (and also override) any brp
scripts from specs that need it and a common scheme for new brps
to follow.
Note that this is not supposed to change the existing behavior and
default build root policy invocations at all, any change in those
would be a thinko/typo/copy-paste error in this commit.
It doesn't belong to redhat-rpm-config which is about *srpm* buildtime..
This reverts commit ea5600c887.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Since b5ea4b290b we started to require gcc
(because annobin requires gcc). Since annobin does work only with gcc,
we don't have to install it if user doesn't have it.
Reported-by: Dominick Grift <dac.override@gmail.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Per fweimer: "Sorry, we need to revert the -Werror=implicit-*
bits. There is no chance we can get this working in any
reasonable time frame, there is simply too much breakage."
Introduce new language specific __global_fooflags for C, C++ and Fortran
This looks mildly strange and suspicious since because the global flags
get pulled in indirectly via %optflags (that doesn't change here but becomes
more obvious).
Depends on previous commit (8fe5b07871)
which was done separately to make the actual change (or lack of thereof)
stand out here.
This is not supposed to change any actual values for current usages,
so if it does it's a bug.
However there's a minor bonus involved for Fortran users who can now get
the correct FFLAGS/FCFLAGS for non-autoconf projects too by using
__global_fflags/fcflags
