On Fri, Mar 9, 2018 at 8:07 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > Some x86_64 packages need a 32-bit glibc during build time. Koji does not > provide it. > > Unfortunately, there is no way to permanently block glibc32 from entering > composes. We have repeatedly asked for it. It simply does not happen. If > end users install glibc32, there system may be irrevocably broken as a > result. > > A few of the current consumers are simply broken in the sense that they > really should build for i686 and get the package thorough the compose > process, instead of building a native x86_64 package. Others may have a > genuine need. > > I thought about removing glibc32 altogether, but this is probably difficult. > I can look at adding a hack to Koji, but there's probably a reason why this > hasn't been fixed in fifteen years (whether it's technical or not), so it's > unlikely to be a good use of my time. > > So as a stop-gap measure, I'd like to add this: > > Conflicts: kernel That's a metapackage now, which isn't actually required for installs. Better to do it on kernel-core, however.. > to the glibc32 package, to make it very unlikely that end users can install > it and completely break there Fedora installation. Buildroots shouldn't > have kernels, so it wouldn't affect them. > > Comments? Suggestions? Buildroots have kernels all the time. Various packages like libguestfs require it because they run virt tests during RPM build. The 4.16-rc4 kernel-core was a component of gnome-software, libtaskotron, plasma-discover, etc. Now, whether or not those also needed glibc32 in the buildroot is a different question. I'm simply pointing out it might not be a safe assumption to assume the kernel/kernel-core packages are never installed in the buildroot. Perhaps it would be better to put: %ifarch x86_64 Conflicts:glibc32 %endif in the kernel spec? josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
