rpm: dkms: Include other kernel-devel packages for spec requirements

[niclimcy]

Motivation and Context

• Fedora users who use LTS kernels depend on a different kernel-devel package (kernel-longterm-devel).
• Similarly, Fedora Asahi Linux users use kernel-16k-devel instead of kernel-devel
• Update spec requirements to include both kernel-devel packages to support these set-ups.
• Should address Longterm fedora kernel depends on different kernel-devel package #16742 and zfs-2.2.5 is looking for kernel-devel when Asahi Linux 40 (Server Edition) uses kernel-16k-devel leading to failed installation #16429

Description

• Replace Requires, Requires(post), and Conflicts with boolean operators according to https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html

How Has This Been Tested?

• Can't seem to build the zfs-dkms rpm packages according to this documentation: https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html#dkms , seem to only get src packages instead.
• Do Fedora 41 builds build the kmod variant instead of the dkms module?

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.

[JMOdero]

Are we sure about the use of "and" in lines 33 and 34? That didn't seem to work for me. I deleted those "ands" and just left one blank space between the "or" boolean statements.... Requires: (x or y or z) (a or b or c)

I didn't test the "Conflicts:" line.

[JMOdero]

I haven't had time to test the "Conflicts:" line. As I previously mentioned openzfs compiled and installed fine without it on my system.

However, I'm wondering if something like this would be better if you wish to include it...

Conflicts: (kernel-devel and kernel-longterm-devel) (kernel-devel and kernel-16k-devel) (kernel-longterm-devel and kernel-16k-devel)

As far as "Conflicts:" goes I don't think we need to get into specific version ranges.

[AllKind]

Suggested change

	Conflicts: (kernel-devel >= @ZFS_META_KVER_MIN@ or kernel-longterm-devel >= @ZFS_META_KVER_MIN@ or kernel-16k-devel >= @ZFS_META_KVER_MIN@) and (kernel-devel <= @[email protected] or kernel-longterm-devel <= @[email protected] or kernel-16k-devel <= @[email protected])
	Conflicts: (kernel-devel < @ZFS_META_KVER_MIN@ or kernel-longterm-devel < @ZFS_META_KVER_MIN@ or kernel-16k-devel < @ZFS_META_KVER_MIN@) and (kernel-devel > @[email protected] or kernel-longterm-devel > @[email protected] or kernel-16k-devel > @[email protected])

[AllKind]

You created a false conflict logic, which will not allow any valid kernel version.
Maybe that's why you are not able to build the rpm packages.

[AllKind]

As far as "Conflicts:" goes I don't think we need to get into specific version ranges.

Of course the versions are needed. You cannot install onto a no longer, or not yet supported kernel version.

[JMOdero]

As far as "Conflicts:" goes I don't think we need to get into specific version ranges.

Of course the versions are needed. You cannot install onto a no longer, or not yet supported kernel version.

Yes, but don't the "Requires:" and "Requires(post):" take care of that?

Like I said before the compile and install worked fine without the conflicts line, and as far as I know with my very limited knowledge openzfs never needed a "Conflicts:" line before in that spec file.

I'm new to all this so I could be very wrong, but isn't the "conflict" that we are concerned about at that stage, using two or more of kernel-devel, kernel-longterm-devel, or kernel-16k-devel when one of a different "flavor" is already in use?

So like my code suggests we are checking to see if we are using say kernel-16k-devel of ANY version and if so then kernel-devel of ANY version is a conflict. At that stage the version is not an issue. If say ANY kernal-longterm-devel is installed then we don't want to install kernel-devel nor kernel-16k-devel of ANY version.

Conflicts: (kernel-devel and kernel-longterm-devel) (kernel-devel and kernel-16k-devel) (kernel-longterm-devel and kernel-16k-devel)

My code suggestion is very clean and clear... Although it may not be correct. I haven't tested it.

Conflicts: (A and B) (A and C) (B and C)

If A and B are both present then the boolean is TRUE and there is a conflict.
If A and C are both present then the boolean is TRUE and there is a conflict.
If B and C are both present then the boolean is TRUE and there is a conflict.

The versions of A, B, and C do not matter at that stage. There is no version number that makes say having A and B at the same time okay.

Version numbers are handled in "Requires:" and "Requires(post):". Making sure we don't have two or more "flavors" of kernel-devel used at the same time seems to be addressed in "Conflicts:".

I think you guys are using too many "ands" and "ors." Looking at the rpm manual...

My "Requires:" and "Requires:(post) are here. It has no "ands" nor "," it is cleaner, and most importantly it works.