RPM: Hold back incompatible kernel packages on Fedora

[tonyhutter]

Motivation and Context

Closes: #17265

Description

A user reported that when your upgrade your kernel packages on Fedora with ZFS installed, only the kernel-devel package gets held back to the ZFS-supported version, but not the other kernel packages. So if ZFS only supports the 6.13 kernel, Fedora will still happily upgrade the kernel RPMs to 6.14, but hold back kernel-devel at 6.13, for example.
This commit includes version checks for the 'kernel' dependency, typically provided by the 'kernel-core' package.

Original-patch-by: @jkool702

How Has This Been Tested?

I tested this on Fedora 41:

1. Downgrade kernel packages from 6.13 -> 6.11
2. Install zfs-2.3.0 (supports up to 6.12 kernel)
3. Remove ZFS repo so it doesn't update past zfs-2.3.0
4. Ran dnf update and verified it only held back kernel-devel, and not the other kernel packages.
5. Added this commit to zfs-2.3.0 source and rebuilt dkms packages
6. Installed new modified zfs-2.3.0 packages.
7. Ran a dnf update and saw it hold back everything:

$ sudo dnf update
Updating and loading repositories:
Repositories loaded.
Problem 1: installed package zfs-dkms-2.3.0-1_g80884de7e.fc41.noarch conflicts with kernel-modules-core > 6.12.999 provided by kernel-modules-core-6.13.12-200.fc41.x86_64 from updates
  - cannot install the best update candidate for package kernel-modules-core-6.11.11-300.fc41.x86_64
  - problem with installed package
 Problem 2: installed package zfs-dkms-2.3.0-1_g80884de7e.fc41.noarch conflicts with kernel > 6.12.999 provided by kernel-core-6.13.12-200.fc41.x86_64 from updates
  - installed package zfs-dkms-2.3.0-1_g80884de7e.fc41.noarch conflicts with kernel-core > 6.12.999 provided by kernel-core-6.13.12-200.fc41.x86_64 from updates
  - installed package zfs-2.3.0-1_g80884de7e.fc41.x86_64 requires zfs-kmod = 2.3.0, but none of the providers can be installed
  - cannot install the best update candidate for package kernel-core-6.11.11-300.fc41.x86_64
  - problem with installed package
 Problem 3: installed package zfs-2.3.0-1_g80884de7e.fc41.x86_64 requires zfs-kmod = 2.3.0, but none of the providers can be installed
  - installed package zfs-dkms-2.3.0-1_g80884de7e.fc41.noarch conflicts with kernel > 6.12.999 provided by kernel-core-6.13.12-200.fc41.x86_64 from updates
  - installed package zfs-dkms-2.3.0-1_g80884de7e.fc41.noarch conflicts with kernel-core > 6.12.999 provided by kernel-core-6.13.12-200.fc41.x86_64 from updates
  - installed package zfs-dracut-2.3.0-1_g80884de7e.fc41.noarch requires zfs >= 2.3.0, but none of the providers can be installed
  - cannot install the best update candidate for package kernel-core-6.11.4-301.fc41.x86_64
  - problem with installed package
 Problem 4: installed package zfs-2.3.0-1_g80884de7e.fc41.x86_64 requires zfs-kmod = 2.3.0, but none of the providers can be installed
  - installed package zfs-dkms-2.3.0-1_g80884de7e.fc41.noarch conflicts with kernel-devel > 6.12.999 provided by kernel-devel-6.13.12-200.fc41.x86_64 from updates
  - installed package zfs-test-2.3.0-1_g80884de7e.fc41.x86_64 requires zfs(x86-64) = 2.3.0-1_g80884de7e.fc41, but none of the providers can be installed
  - cannot install the best update candidate for package kernel-devel-6.11.4-301.fc41.x86_64
  - problem with installed package

Package                                                                 Arch             Version                                                                  Repository                                    Size
Skipping packages with conflicts:
 kernel-core                                                            x86_64           6.13.12-200.fc41                                                         updates                                   75.3 MiB
 kernel-devel                                                           x86_64           6.13.12-200.fc41                                                         updates                                   77.8 MiB
 kernel-modules-core                                                    x86_64           6.13.12-200.fc41                                                         updates                                   37.8 MiB

Nothing to do.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[jkool702]

EDIT now that ive actually tested it.

I think that we might actually need something more like tonyhutter@f606c29 to have DNF work reasonably. Use "Requires" and "Conflicts" for the kernel packages zfs actually requires, and just use "Conflicts" for most things it'll prevent ther new kernel packages from installing without breaking DNF and will not cause zfs-dkms to needlessly pull

Details of "why" are in #17265 (#17265 (comment)), but basically Im hoping that by just using "Conflicts" for most things it'll prevent the incompatable new kernel packages from installing without breaking DNF and will not cause zfs-dkms to needlessly pull in all the kernel subpackages.

Ive tested this and it seemingly makes everything work like it should on 2.3.1 with an available kernel 6.14.3 update. See #17265 (comment) for a more details.

[jkool702]

@tonyhutter - I made a PR with the changes described in my last comment to the tonyhutter/zfs branch that is the source of this PR.

[tonyhutter]

It's more of a formality, but I will need to add these for RHEL8 (RHEL9 uses kernel-modules-core):

Requires:       kernel-modules >= @ZFS_META_KVER_MIN@, kernel-modules-core <= @[email protected]
Requires(post): kernel-modules >= @ZFS_META_KVER_MIN@, kernel-modules-core <= @[email protected]
Conflicts:      kernel-modules < @ZFS_META_KVER_MIN@, kernel-modules-core > @[email protected]

Let me do that and retest.

[tonyhutter]

I ended up refactoring this PR to just add...

Requires:       kernel >= @ZFS_META_KVER_MIN@, kernel <= @[email protected]
Requires(post): kernel >= @ZFS_META_KVER_MIN@, kernel <= @[email protected]
Conflicts:      kernel < @ZFS_META_KVER_MIN@, kernel > @[email protected]

... and nothing else. The 'kernel' dependency is typically provided by the 'kernel-core' package. That should be all we need to build the dkms packages on EL and Fedora. I'm pretty convinced this minimalist route is the best way to go. The alternative is add Conflicts lines for every kernel related package, even though ZFS doesn't require them, which seems wrong, and requires constant whack-a-mole whenever distros add a new kernel-* package.

[jkool702]

@tonyhutter - I see the appeal of the minamalist route. im less convinced, but this in probably a reasonable initial change to make.

I guess my thoughts are that is that its less about "what zfs needs" and more about "not letting the system install stuff that will be broken as a direct result of things zfs is blocking". This is an incompatable kernel, and so (sort of by definition) zfs wont have what it needs until there is an update for zfs that supports the new kernel.

In many ways, the existing behavior is the minimalist route - zfs blocks only what is needed to prevent building potentially broken zfs kernel modules and leaves everything else alone. And, ignoring everything other than zfs, it achieved this goal quite well. The issues caused werent really "problems with zfs", but were "problems from installing a kernel that couldnt build new modules on a system that uses locally-compiled kernel modules".

I feel like blocking kernel-core but not blocking the rest of the kernel packages is sort of just trading one "problem stemming from a partially installed kernel" for another. Granted, installing things like kernel-modules-extra for kernels that arent installed on the system is probably a less severe problem. However...I cant think of many situations where these modules would be useful (exclusing for kernel developers), but I can think of a few where they might cause issues (e.g., with anything that assumes that the existance of /lib/modules/$kver means that kernel $kver is installed).

That said, not having to constantly update the list of kernel subpackages to block and notr blocking stuff zfs never uses are both a big plus, and it should be much better than the current situation, and having something like kernel-modules-extra update early mightr not cause any big problems, so...just blocking kernel is probably a reasonable initial change.