packages which require the kernel package

drago01 drago01 at gmail.com
Mon Mar 10 19:32:20 UTC 2014


On Mon, Mar 10, 2014 at 8:22 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> 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?

Well some of them (ex. pulseaudio) just require kernel >= something
which could either be removed if the
kernel version is ancient or turned into conflicts. Conflicts might be
problematic in theory because we allow multiple
kernels to be installed but given how ancient they are I doubt it
matters in practice.


More information about the devel mailing list