On Fri, Apr 16, 2021 at 3:57 PM Paul Bolle pebolle@tiscali.nl 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...)
While x86_64 and i686 were unified a little over 10 years ago (the kernel-headers files are identical), they can't be noarch because other architectures are different. Both rpm and dnf have really crap support for multilib. If we just build the x86_64, i386 builds cannot resolve kernel-headers as a dep. The kernel-cross-headers package could definitely be noarch, but it wasn't added that way, and I had not bothered to fix it.
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 to 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?
Yes, though there is no guarantee of an rc8, so the best time would be the weekend before rc7 to give people time to test and review before the merge window opens.
Justin