On 14 January 2016 at 19:29, Andrew Lutomirski <l...@mit.edu> wrote: > > On Jan 14, 2016 9:34 AM, "Nicolas Chauvet" <kwiz...@gmail.com> wrote: >> >> 2016-01-14 18:05 GMT+01:00 Neal Gompa <ngomp...@gmail.com>: >>> >>> On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald <h.rei...@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 http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
