All these years, enabling debuginfo has required distros to hijack the
spec %install section with a macro like this:
%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}
This for a widely used, longtime upstream supported feature is just
gross, and also very non-obvious, feeble and whatnot. And totally
prevents the new append/prepend options from being used with %install.
Take advantage of several newish features to make this happen: we need
expressions to properly handle the numeric %_enable_debug_packages value
from a macro, and if enabled, output the debuginfo template as a dynamic
.specpart.
Enable debuginfo on Linux by default in the platform configuration.
Notably noarch should not have debuginfo so it's disabled in the
platform configuration - since 96467dce18
we can now actually rely on the platform configuration being valid,
so we can drop the "%ifnarch noarch" from the debug package check.
Further streamlining should be possible.
Note that the old %install hack MUST BE REMOVED from distros now.
As a nice bonus, this makes debuginfo work for packages that don't use
%setup. Add an explicit test for this in the "rpmbuild %caps" test.
specstep.spec needs to be made noarch here, otherwise it'll now try
to produce debuginfo and fail.
Co-authored-by: Florian Festi <ffesti@redhat.com>
Fixes: #2204Fixes: #1878
* Allow setting platform macro settings externally
By default, rpm installs a series of default platforms based on
the CPU architecture names in subdirectories called
/usr/lib/platform/<arch>-<os>
This is enough for regular Linux distributions. However, some
distributions may use more specific platform names that refer to
particular computer systems, like SBCs or specific CPU tuning when
compiling.
If the platform subdirectory does not exist in /usr/lib/platform
then rpmbuild does not work.
Allow creating such custom platform subdirectory with feeding
the necessary data using external variables: RPM_CUSTOM_ARCH,
RPM_CUSTOM_ISANAME, RPM_CUSTOM_ISABITS, RPM_CUSTOM_CANONARCH
and RPM_CUSTOM_CANONCOLOR
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
---------
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Co-authored-by: Florian Festi <ffesti@redhat.com>
The x86_64 SysV psABI defines four levels of x86_64 with certain CPU
features required for each level. Those definitions are meant to be
generically useful and recognized as such by glibc and gcc as well.
For backward-compatibility and to avoid surprises, default to building
x86_64 even on v2+ capable machines.
Some of the replacements in platform.in are expected to be processed
by the build system configuration file, whereas others are replaced
by installplatform at the time of install. Use =VAR= notation instead
of @VAR@ to differentiate the latter from the former.
No functional changes, just makes it easier to understand and handle.
- The sed-munger added in commit ccd6281e69
causes bigger breakage than it fixes, perhaps because the hammer
applied was disproportionally large. The only thing needing adjustment
is ${prefix} in case when localstatedir is not explicitly set, so
we fixup just that instead of "everything".
- Discovered via RhBug:921973 testing
IBM recently announced the OpenPOWER Consortium, part of this initiative
means now powerpc hardware can run the little endian mode. Create a new
platform for that mode of opperation.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Autoconf leaves things like @localstatedir@ unexpanded at build-time
on purpose so the paths can be overridden during "make install".
However this leaves %{_var} in macros in its unexpanded state
unless --localstatedir is explicitly passed in, which does not
work very well for rpm.
- Process the main macros file through the same meat grinder as
the platform macros. Ugly as sin but... it brings the casual
"./configure; make; make check" sequence much closer to working.
Here is my updated patch adding AArch64 support. The main change was to
use CANONCOLOR=3 rather than 2.
--Mark
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- The filter wasn't doing what it was supposed to due to extra single
quotes getting inserted, causing "rpmbuild --target noarch foo.spec"
to whine about empty macro bodies. This is a regression introduced
in rpm 4.10, commit 07ec480c18 to be
precise.
- loop over all archs known by rpmrc but only generate the platform config
if all necessary parameters (such as ISA information) are known, this
gives a reasonable idea of what archs are *really* in use and supported
- at least in theory, the platform configuration could now move to
$datadir as the contents no longer depend on which are rpm was built on
- also gets rid of the big sed-monster in install-platform
- eliminate unused target and target_platform variables
- eliminate unnecessary temporary rpmrc (used to make a difference when
macro path was in there, not anymore)
- Horrible kludgery to get the isa names and bits into platform specific
macros from installplatform script. That beast needs to die. I mean really
- In build, add provides: name(isa) = evr automatically when it makes
sense (similarly to name = evr provides). ISA consists of ISA name and
bitness (or wordsize). This can be used to correctly
express multilib dependencies without resorting to (expensive!) file
dependency kludges, eg for dlopen()'ed libraries where automatic
dep extraction doesn't force dependency on 32bit vs 64bit version, you
can now use:
Requires: foo-plugin%{?_isa}
This expands to foo-plugin(x86-32) for i?86 packages, foo-plugin(x86-64)
to x86_64 etc, and permits spec to be shared with older distros which
don't have ISA provides.
- The same could be expressed with "canon arch" just as well, but
using the ISA to differentiate from %_arch and the like:
eg i386 could be used instead of x86-32 but it's overloaded with meanings
(the actual i386 processor vs i386 compatible cpu family etc)
Michal Čihař