On Jan 14, 2016 9:34 AM, "Nicolas Chauvet" <kwizart(a)gmail.com> wrote:
>
> 2016-01-14 18:05 GMT+01:00 Neal Gompa <ngompa13(a)gmail.com>:
>>
>> On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald <h.reindl(a)thelounge.net>
>> wrote:
>> >
>> > Am 14.01.2016 um 16:56 schrieb Neal Gompa:
>> >>
>> >> I've recently been wondering why we haven't allowed kernel
module
>> >> packages in Fedora since Fedora 8. I've tried searching through our
>> >> wiki and the mailing list, but I haven't come up with any concrete
>> >> reasons for why we disallow them.
>> >>
>> >> If it is perhaps the issue of keeping things in sync with kernels we
>> >> provide (that is, maintainers didn't/couldn't keep up with new
kernels
>> >> being pushed during a release cycle), then I think the situation has
>> >> changed.
>> >>
>> >> We have two tools that can help us in this regard: akmod and Koschei,
>> >> both came after our policy change to disallow kernel modules.
>> >
>> >
>> > akmod is a dirty hack and fails often enough for rpmfusion stuff
>> >
>> > additionally you should *never* need GCC and devel packages installed
>> > on a
>> > normal enduser system for a ton of reasons
>>
>> The most common reason that akmod fails is the same reason dkms often
>> fails: the correct kernel-devel isn't installed. For whatever reason,
>> there's no logic in DNF to handle this case properly. Of course, to be
>> fair, this problem happens in Yum too, but since Yum isn't actively
>> supported in Fedora anymore, it's not as much of a concern.
>
>
> Maybe this particular concern can be addressed in DNF with a plugin ?
>
> The way I've previously worded a possible solution is to have a yum/dnf
> plugin for akmod.
> This plugin will select the appropriate kernel-devel based on the kernel
> that is currently installed.
> (
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
>
> But this dnf plugin can be useful by default in fedora, since the
> kernel-devel issue can rise when one user install a particular development
> group where kernel-devel is needed.
> (user typically ends with kernel-debug-devel instead of the one for their
> kernel variant that can also be kernel-lpae or else).
There are two issues here, I think:
1. Is Fedora okay, in principle, with shipping out-of-tree modules?
I won't comment on #1. (I also won't comment on Secure Boot issues.)
2. Assuming that shipping an out-of-tree module is okay, is akmod a good
mechanism?
I would argue strongly that akmod is *not* a good mechanism.
Clearly any end-user-box-builds-modules system needs the package manager to
pull in the right devel stuff. This is clearly a solvable problem.
But akmod in particular has a really nasty built-in assumption: it assumes
that the running kernel came from an RPM at all. For people who write
kernels, this utterly sucks. For example, I have no intention of rpm-ifying
every test kernel I build for my laptop. I install them according to the
standard arrangement, which "make install" can do just fine. There are
symlinks in standard places that a kmod build system could find. Akmod
can't do that. Akmod also can't figure out what to make its freshly-built
rpm depend on because there is no correct answer.
I think that, if Fedora were to adopt a kmod build system: it should have a
QA requirement: if you "make modules_install && make install" a kernel
and
boot into it, the kmod system should work. Akmod fails utterly in that
scenario.
I don't quite get this one, if you build any package from a non-rpm
source it's not a given that rpm modules will work with it. Akmod is
really a convenience for people reliant on non-tree modules who are
also using the distribution rpm kernel, so they have a chance of
getting a working module whenever the kernel updates. If you're
building your own kernel you probably know when you've done it and how
to build the module.
--
imalone