On Fri, Mar 9, 2018 at 8:44 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 03/09/2018 02:21 PM, Josh Boyer wrote: > >>> 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.. > > > Noted. > >>> 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. > > > Hmm. Do you think it's still worth a try? Maybe. We could add it and see what breaks. Might be a nice way to figure out if people have incorrect dependencies on things too, but I suspect there are a few cases where this might cause issues with valid usage. >> Perhaps it would be better to put: >> >> %ifarch x86_64 >> Conflicts:glibc32 >> %endif >> >> in the kernel spec? > > > What's the improvement compared to the glibc32 change? Would we still add > that to the kernel-core package? I guess, now that I've had coffee, there isn't really a difference. Stepping back a bit, I'm curious why glibc32 would land in the composes. It shouldn't... it should only be tagged in the fNN-build tags, which the composes should not pull from. Where do we have recent issues of it getting pulled into a compose? josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
