If I am not mistaken, Fedora doesn't *ship* gcc.i686 nor libstdc++-docs.i686. The are built though, see e.g. gcc-13.1.1-3.fc39 [1], they just get discarded somewhere later in the pipeline before landing in Fedora repos. I'd like to have them removed sooner, in the build phase (do not build them or delete them at the end). They are troublemakers from several points of view: 1. They conflict with their x86_64 counterparts. As a consequence, any time you download a full GCC build like koji download-build --arch={x86_64,i686,noarch} <build> you have to remove the two RPMs before trying to install the build. And this workaround has to be applied in every setup script over and over again. 1. They significantly slowdown distro-wide automatic tests like fedora-ci.koji-build.rpmdeplint.functional [2]. That particular test is very sensitive to amount of the files present in the RPMs being tested. I believe that not testing libstdc++-docs.i686 will shave 30-40% of the test time, possibly preventing timeouts like the one observed in [2]. Thanks for considering! [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2203015 [2] https://artifacts.dev.testing-farm.io/7eb9da00-48cd-4c25-876b-abad7033f7f4 Reproducible: Always
libstdc++-docs is slow to build, so skipping that for the i686 builds would speed them up.
This is not how Koji works. We need gcc.i686 in the Koji buildroot, so we have to build it, otherwise the i686 builders will not work. I do not think we need libstdc++-docs on the builders, so we could probably drop it.
Ah, of course, the buildroot :-) Thanks for reminding me! I hope dropping libstdc++-docs.i686 is feasible.
Yeah. All the gcc* subpackages of gcc + libstdc++-docs are non-multilib, they need to be built for the 32-bit buildroot to function, but for any of the composes, they should be only included from the primary arch (x86_64 in the x86-64 case). I don't think libstdc++-docs is worth bothering with in the spec file, it isn't slow compared to the hours of lto profiled bootstrap and make check.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.