On Fri, Apr 16, 2021 at 10:57:44PM +0200, Paul Bolle wrote:
Justin Forbes schreef op vr 16-04-2021 om 13:33 [-0500]:
> The only thing that RHEL builds i686 at all is kernel-headers and
> kernel-cross headers. For Fedora, kernel-headers is a separate package.
Glad I asked, because I hadn't realized this. And apologies for yet another
email. In over a year I only delivered some messages...
> Those likely need to remain for 32bit userspace packages.
(More a note to self: dnf doesn't lists either kernel-headers.i686 or kernel-
cross-headers.i686. Perhaps that is because they appear to ship identical
files. But why bother building them for i686? And why is kernel-cross-headers
not a noarch file? Ie, what explains the differences between k-c-h.aarch64, k-
c-h.arm7hl, etc. Lot to learn here...)
We can't make headers noarch: even if x86_64 and i686 headers package
contents are the same, the other arches should be different, so how you will
differentiate binary packages for other arches.
About building the i686 packages, we think we still need them for koji/brew
dependency solving, eg. when building glibc i686 there (i686 repos are used).
RHEL uses the headers provided by the kernel package, so it must still provide
kernel-headers and kernel-cross-headers for i686, but other than that,
everything else i686 related can be dropped I think.
> I haven't seen your patches, but it seems the first step would be to remove
> anything that builds/verifies the i686 configs, this can include the
> i686 config directories (but don't move x86_64 up to x86). I might
> also remove filter-i686* and stop it from being called as well.
That was sort of my approach: first clean up the specfile, then remove
anything that has then become unreachable.
> Once nothing is using those configs, we can look at rearranging x86/x86_64
> to just be a single x86 directory in a separate change.
This is what my "configs: there's only x86_64" commit does. That turned out
be much simpler than I feared.
> Doing it this way should make it a bit easier to get that patch through quickly
> without too much churn. It can also be better arranged around the
> merge window, which is when config options change the most.
My English is letting me down here, but config churn is lowest at the end of
the dev. cycle, so config cleanup is best done around rc7 or rc8, right?