Bug 1058331

The macros to faciliate the change have already been incorporated in rpm (bug 1025513). It may be in the kernel spec shortly.

*** Bug 1071521 has been marked as a duplicate of this bug. ***

OK, so I enabled this locally.  The good news is that it works:

[jwboyer@vader 0.rc3.git4.6.fc21.1]$ rpm -qp --provides kernel-core-3.15.0-0.rc3.git4.6.fc21.1.x86_64.rpm | tail -n 4
kmod(zlib.ko)
kmod(zlib_deflate.ko)
kmod(zlib_inflate.ko)
kmod(zram.ko)
[jwboyer@vader 0.rc3.git4.6.fc21.1]$ 

The good yet not good news is that it works for all modules in all kernel flavor packages:

[jwboyer@vader 0.rc3.git4.6.fc21.1]$ rpm -qp --provides kernel-debug-core-3.15.0-0.rc3.git4.6.fc21.1.x86_64.rpm | tail -n 4
kmod(zlib.ko)
kmod(zlib_deflate.ko)
kmod(zlib_inflate.ko)
kmod(zram.ko)
[jwboyer@vader 0.rc3.git4.6.fc21.1]$

What that shows is that both the kernel-core and kernel-debug-core packages e.g. Provides:kmod(zram.ko).  This would be similarly true for any kernel package that has modules, so i686 and PAE, PAEdebug, etc.  It would also mean that if you had both the x86_64 and i686 versions in the same repo, they would both satisfy a Requires: kmod(zram.ko).  I don't believe this is what we actually want.

If a package such as gfs2-utils has:

Requires: kmod(gfs2.ko)

we want it to resolve to the kernel that is going to be installed or is already installed in the case of a missing kernel-modules or kernel-modules-extra package, not whatever comes first according to yum.  If we make the Provides more explicit like:

Provides: kmod(gfs2.ko)-uname-r = 3.15.0-0.rc3.git4.6.fc21

or

Provides: kmod(gfs2.ko)-uname-r = 3.15.0-0.rc3.git4.6.fc21+debug

(similar to the kernel-uname-r provides), then a package can't generically say "I want the gfs2 module installed".

I'm not sure how exactly to solve this as we originally intended.

I don't think there is a way to perfectly solve the problem. I think this is still better than requiring kernel-modules-extra since in theory modules can switch between kernel-modules and kernel-modules-extra.

If the dep solver tries to bring in the minimum number of packages to provide the dep, then this will normally work as expected. For depsolves that grab everything, then you'll need to exclude stuff, but we do that already for spins.

(In reply to Bruno Wolff III from comment #4)
> I don't think there is a way to perfectly solve the problem. I think this is
> still better than requiring kernel-modules-extra since in theory modules can
> switch between kernel-modules and kernel-modules-extra.

Yeah, that's a fair point.  I believe we already have an identical problem with just Requires: kernel-modules-extra anyway.

> If the dep solver tries to bring in the minimum number of packages to
> provide the dep, then this will normally work as expected. For depsolves
> that grab everything, then you'll need to exclude stuff, but we do that
> already for spins.

I'm mostly concerned about fresh installs.  I'm not sure how anaconda will resolve the deps if a user were to include a package that has a Requires: kmod(foo.ko) and both i686 and PAE are avaiable.  Perhaps the PAE install criteria would kick in and it would select the PAE flavor appropriately.

I've created a copr with the autoprov enabled and the impacted packages switched over to doing Requires: kmod(whatever) instead of kernel-modules-extra.  Once the kernel build finishes, we can play around with it and see how things look.

http://copr-fe.cloud.fedoraproject.org/coprs/jwboyer/kernel-kmod-autoprov/

Thanks for the heads up. I'll play with this over the weekend.

Created attachment 892188 [details]
yum output

I am unable to update to kernel-PAE from the copr repo.

(In reply to Bruno Wolff III from comment #8)
> Created attachment 892188 [details]
> yum output
> 
> I am unable to update to kernel-PAE from the copr repo.

Yeah, I fixed that bug this morning in rawhide.  I've started another build in the copr that hopefully fixes that issue.

Created attachment 892262 [details]
yum output

So the upgrade to 3.15.0-0.rc3.git5.7.fc21.2 went OK. When I tried to install joystick-support, yum did ended up pulling in kernel-PAE-modules-extra to match the installed PAE kernel. However, kernel-PAE-modules-extra couldn't be installed.

(In reply to Bruno Wolff III from comment #10)
> Created attachment 892262 [details]
> yum output
> 
> So the upgrade to 3.15.0-0.rc3.git5.7.fc21.2 went OK. When I tried to
> install joystick-support, yum did ended up pulling in
> kernel-PAE-modules-extra to match the installed PAE kernel. However,
> kernel-PAE-modules-extra couldn't be installed.

Yeah.  Same bug, different flavor.  I'll get it right eventually.  New build started.  Sadly, none of the issues you're seeing have anything to do with this bug.  Thanks for your patience.

With 3.15.0-0.rc3.git5.8.fc21.2 things work as expected using yum to install joystick-support without already having kernel-PAE-modules-extra installed. It installs the PAE version to match the installed kernel. However, it doesn't install it for the running kernel, instead using the latest kernel. That's expected as a limitation with how kernel installs work.
Removing kernel-PAE-modules-extra triggered the removal of joystick-support.
I tested the same using dnf and it worked the same way.
I want to test using livecd-creator and an anaconda install to see if they work as expected with respect to PAE / non-PAE kernels, but I am not going to get to that tonight.

Auto provides for kernel modules has been enabled in kernel-3.15.0-0.rc5.git2.8.fc21, which should show up in tomorrow's rawhide barring unexpected issues.
You can now use contructs like kmod(joydev.ko) to make sure the joystick driver is installed, instead of requiring kernel-modules-extra. This also makes packages proofed against modules moving between kernel-modules and kernel-modules-extra.

I have patches to attach to each of the bugs blocking this one.  I'll try and do so later today.

In local assembly I correct this problem so the patch -- https://github.com/solooboroten/fedora-kernel/commit/78ed1231503d10c8d7f6582c02e99c8ccab1be3b. This solution is not as beautiful as pridlagaemoe, but it can satisfy the dependence existing in the repository packages without recompiling.

In local assembly I correct this problem so the patch -- https://github.com/solooboroten/fedora-kernel/commit/78ed1231503d10c8d7f6582c02e99c8ccab1be3b. This solution is not as nice as suggested, but it can satisfy the dependence existing in the repository packages without recompiling.

PS: This is a corrected version https://bugzilla.redhat.com/show_bug.cgi?id=1058331#c15.

(In reply to Aleksey Avdeev from comment #16)
> In local assembly I correct this problem so the patch --
> https://github.com/solooboroten/fedora-kernel/commit/
> 78ed1231503d10c8d7f6582c02e99c8ccab1be3b. This solution is not as nice as
> suggested, but it can satisfy the dependence existing in the repository
> packages without recompiling.
> 
> PS: This is a corrected version
> https://bugzilla.redhat.com/show_bug.cgi?id=1058331#c15.

That patch doesn't seem to have anything to do with this specific bug, and I have no idea why it's necessary.  Could you explain the problem you're having?  If it isn't with the automated .ko provides, you should probably open a new bug.

Issues with PAE vs non-PAE kernels have been moot for a while now.