When Fedora is in a container (a la Docker), the kernel comes from the host, not the installed package set. I noticed a number of packages which actually have a requirement on the kernel package. This isn't very helpful, since the installed package says nothing about the running one, and forcing the package doesn't help. For many of these, the requirement is actually that the running kernel have a certain feature, and the hope is that the package version check will do it. For others, like ipset, I'm not quite sure -- there's a spec file comment that says "This is developed hand in hand with a kernel module", but it then just says "Requires: kernel". I think quemu-sanity-check may be the only one that actually really wants a kernel. Possibly libguestfs too -- I didn't dig too deepy. There aren't actually a lot: autofs fedfs-utils-lib / fedfs-utils-server (from fedfs-utils) firehol ipset libguestfs lldpad mod_selinux netlabel_tools ovirt-guest-agent-common (from ovirt-guest-agent) pulseaudio qemu-sanity-check sysprof systemtap-devel / systemtap-runtime (from systemtap) vdsm Some of these probably have very good reasons for really needing the kernel package to be there. I'm pretty sure that many of the others don't. I propose that (in Rawhide) we simply drop the requires line from all of the ones that are simply trying to state that they need a kernel version greater than the kernel version currently in Rawhide (right now, 3.14 rc). I think that would cover all of the above except Richard W.M. Jones's stuff, and ipset, which I *think* doesn't really need it. (And systemtap-devel should probably change its requirement on kernel-devel to have the version information there.) Optionally, vdsm is the only one with a requirement on anything greater than the 3.9.5 kernel which originally shipped with F19 (but less than the 3.11.10 that shipped with F20). That one could be left until F19 is EOL. Most of these aren't at any risk of actually getting pulled into a container (and don't belong there), but the requirements also seem wrong so I thought we might as well go and clean them up. What do you think? -- Matthew Miller -- Fedora Project -- <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
