Re: packages which require the kernel package

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 10, 2014 at 8:22 PM, Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx> 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.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux