#629 Issue closed: RPM BuildArch noarch contradicts arch specific bootloader RPM requirement¶
Labels: fixed / solved / done
jsmeix opened issue at 2015-07-29 08:20:¶
@k0da (cf. https://github.com/rear/rear/pull/627) found the following issue:
"BuildArch noarch" contradicts arch specific bootloader RPM requirement.
Currently rear.spec contains (excerpt):
BuildArch: noarch ... %ifarch %ix86 x86_64 Requires: syslinux %endif %ifarch ppc ppc64 Requires: yaboot %endif
This cannot work because when it is built for "noarch" none of the %ifarch matches which means neither syslinux nor yaboot will be required by the resulting *.rpm package.
In general I think rear should not be built as "noarch".
I think rear should be built as a regular architecture dependent package.
Reasoning:
In fact rear is not "noarch" because it only works on those architectures that are explicitly supported by rear.
Of course the rear bash scripts can be installed on any architecture just as any binaries can be installed on any architecture.
But I think the meaning of architecture dependent packages is on what architectures they will work.
I think instead of "noarch" in the spec file only those architectures that are actually supported by rear should be explicitly listed.
Additionally this would avoid that the rear bash scripts can be "just installed" on architectures that are actually not supported by rear (e.g. IBM z Systems).
schlomo commented at 2015-07-29 11:22:¶
@jsmeix good point and convincing for me. The RPM that we build for a specific platform should indeed be optimized for that platform. Since a rear RPM should be different when built for PPC or for x86_64 it should not be noarch. IMHO a requirement for noarch would be that the RPM is really the same on all architectures.
Theoretically one could split the ReaR RPM into rear, rear-lib, rear-doc etc. subpackages where only the rear package would be architecture dependant. Or where rear-lib would be architecture dependant and only contain the relevant paths (there was once a request for that). Or ...
But I actually think that this would be really overkill :-)
Will you provide a pull request?
jsmeix commented at 2015-07-29 12:43:¶
Please no package split (of course unless you like to get into more trouble ;-)
Split packages always cause issues when users install only some parts or mix up parts that do not match together (yes of course theoretically with sufficient RPM dependencies all that can be defined perfectly well - provided someone actualy implements it ;-)
On Fedora it seems there are different opinions when a package is
"noarch", see
https://www.redhat.com/archives/fedora-packaging/2006-July/msg00121.html
and the follow up mails.
The Fedora Packaging Guidelines contain
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
Requires
When your package needs the problematic dependency at runtime but not at build time then you only need to keep it from entering the package repositories for that architecture. There is a relatively simple workaround for this:
BuildArch: noarch
# List the arches that the dependent package builds on below
ExclusiveArch: %{ix86} %{arm} x86_64 noarch
I don't know if
BuildArch: noarch ExclusiveArch: %ix86 x86_64 ppc ppc64 noarch
is allowed and/or works on openSUSE.
I will ask how to do it correctly in the openSUSE Build Service
and provide a pull request when I know how to do it.
gdha commented at 2015-07-30 09:08:¶
I like the phrase from https://www.redhat.com/archives/fedora-packaging/2006-July/msg00130.html:
The only vaguely valid case is combining BuildArch noarch and ExcludeArch,
which is like saying "by nature, the package contents are arch-independent,
but we know that there is a problem on the N excluded arches".
jsmeix commented at 2015-07-30 13:10:¶
But the same mail https://www.redhat.com/archives/fedora-packaging/2006-July/msg00130.html also states:
Instead of combining BuildArch noarch and ExclusiveArch, just drop BuildArch noarch and create arch-specific packages. Especially if there is a dependency on other arch-specific packages.
Currently I would prefer
ExclusiveArch: %ix86 x86_64 ppc ppc64 %ifarch %ix86 x86_64 Requires: syslinux %endif %ifarch ppc ppc64 Requires: yaboot %endif
I don't like ExcludeArch because that will silently and automatically result non-working RPM packages when a strange new architecture gets enabled (like ARM or whatever).
Experienced users who like to try out if a current rear also works on a new architecture can enforce to install any RPM on their own or get the current rear files directly from GitHub.
From my point of view a ready-to-use RPM package implicitly tells an end-user that it is know to work which means one should not provide RPM packages for architectures that have never been tested.
k0da commented at 2015-07-30 13:17:¶
What about using recommends?
syslinux is required on x86 because it is not standard bootloader, but the one used for isos.
For grub2, yaboot or whatever. This could be dropped. Since those are default bootlaoders and could be used for ISO boot as well.
schlomo commented at 2015-07-30 13:25:¶
Recommends is a DEB concept (so far). We already had several times the
discussion if our RPMs should require more or less packages. Different
people have different use cases and opinions and nobody bothered to
create
for example a rear-usb-backup subpackage that would pull in everything
needed for bootable USB drvives...
On 30 July 2015 at 15:17, Dinar Valeev notifications@github.com wrote:
What about using recommends?
syslinux is required on x86 because it is not standard bootloader, but the
one used for isos.For grub2, yaboot or whatever. This could be dropped. Since those are
default bootlaoders and could be used for ISO boot as well.—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/629#issuecomment-126320077.
jsmeix commented at 2015-07-30 13:42:¶
I cannot decide here what bootloader packages should be required or recommended because I do not have sufficient knowledge to make such decisions.
RPM recommends also work on openSUSE (I don't remember since what exact openSUSE version) - I use them often in my printing packages (probably even more often than explicit requirements).
My primary concern here is how to get it solved in general that rear "needs" (requires or recommends) architecture dependent packages.
For example if yaboot is by default installed on ppc ppc64 and also used there to make the bootable ISO image it could be simplified to only
ExclusiveArch: %ix86 x86_64 ppc ppc64 %ifarch %ix86 x86_64 Requires: syslinux %endif
In the end this should tell the end-user that rear is known to work only on %ix86 x86_64 ppc ppc64 and on %ix86 x86_64 syslinux is explicitly required (in addition to the default installed bootloader grub) to make the bootable ISO image.
schlomo commented at 2015-07-30 13:45:¶
Would this work? Then it looks good to me.
On 30 July 2015 at 15:42, Johannes Meixner notifications@github.com wrote:
I cannot decide here what bootloader packages should be required or
recommended because I do not have sufficient knowledge to make such
decisions.My primary concern here is how to get it solved in general that rear
"needs" (requires or recommends) architecture dependent packages.For example if yaboot is by default installed on ppc ppc64 and also used
there to make the bootable ISO image it could be simplified to onlyExclusiveArch: %ix86 x86_64 ppc ppc64
%ifarch %ix86 x86_64
Requires: syslinux
%endifIn the end this should tell the end-user that rear is known to work only
on %ix86 x86_64 ppc ppc64 and on %ix86 x86_64 syslinux is explicitly
required (in addition to the default installed bootloader grub) to make the
bootable ISO image.—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/629#issuecomment-126328397.
jsmeix commented at 2015-07-30 13:46:¶
I need a bit of time to test it...
jsmeix commented at 2015-07-30 16:48:¶
The actual change was easy.
Now it is only
ExclusiveArch: %ix86 x86_64 ppc ppc64 %ifarch %ix86 x86_64 Requires: syslinux %endif
Only for testing I also tried
ExclusiveArch: %ix86 ppc ppc64 %ifarch %ix86 x86_64 Requires: syslinux %endif %ifarch ppc ppc64 Requires: yaboot %endif
and this does no longer build it on x86_64 (as expected) and on ppc
there was the requirement for yaboot (but not elsewhere).
Accordingly everything seems to "just work" as expected.
For the fun:
I had the obviously bad idea to "just by the way" also clean up the incomplete and outdated changelog entries with one generic entry that is always valid and that one was the real hard part - see my Git commit comments ;-)
jsmeix commented at 2015-09-03 14:37:¶
Right now I noticed that in openSUSE Build Service there exists also the architectures ppc64p7 and ppc64le.
I assume when rear is supported on ppc and ppc64 then it is perhaps also supported on architectures like ppc64p7 and ppc64le?
@k0da
could you confirm whether or not rear is also supported on architectures
like ppc64p7 and ppc64le?
If rear is also supported on ppc64p7 and ppc64le the spec file should be enhanced to
ExclusiveArch: %ix86 x86_64 ppc ppc64 ppc64le ppc64p7
k0da commented at 2015-09-03 14:45:¶
well, ppc64p7 is something Fedora invented. OBS supports this but we have none SUSE distro built for it.
ppc64le definetely. Both openSUSE Tumbleweed and SLES12 have support for ppc64 little endian
gdha commented at 2015-09-11 15:31:¶
@jsmeix moved the milestone for the latest changes that are not yet implemeneted
jsmeix commented at 2015-09-14 11:01:¶
I need feedback from Fedora users whether or not rear is also supported on ppc64p7.
jsmeix commented at 2015-10-13 07:45:¶
For the record:
ppc64le also works on RHEL7 according to https://github.com/rear/rear/issues/663#issuecomment-145797975
ppc64le is added to rear.spec via https://github.com/rear/rear/pull/665
gdha commented at 2016-02-09 13:30:¶
@jsmeix do you still want to keep this issue open for tracking or not?
jsmeix commented at 2016-02-09 14:05:¶
I think it is currently sufficiently solved.
Therefore I close it.
[Export of Github issue for rear/rear.]