Description of problem:
When installing the systemtap-devel package, there is a kernel-devel dependency.
But since any kernel-devel varriant (PAE/lpae/etc) has the kernel-devel virtual provide, it's not possible to prefer kernel-devel over kernel-debug-devel.
I sugguest to drop the kernel-devel virtual provide in the kernel package and to use the right virtual as kernel-devel-uname-r
Version-Release number of selected component (if applicable):
current version in devel
dnf install systemtap-devel
kernel-devel-debug is installed (which might be right for systemtap, but not if using the regular kernel package)
it should install the kernel-devel matching the kernel (or at least the statistically best candidate).
see also rhbz#1420754
I think I see what you are trying to do here, and the 'kernel-devel-uname-r' virtual provide is certainly new to me.
Is this going to work in the case of: you've got the regular kernel installed and then install systemtap. That will pull in kernel-devel. You then install the debug kernel. Is the latter operation going to pull in kernel-debug-devel?
One more question. In what version of Fedora was kernel-devel-uname-r introduced? In what version of RHEL was it introduced?
Short answer no:
Moving to kernel-devel-uname-r only move to a virtual provide, over using a "not so much virtual" provide because it's also the name of a real-package.
Unfortunately this is not what will make it select kernel-devel as the preferred package.
In the current packaging (allowing weak dependencies), the current best method is described in the guideline, as real life example:
So that would ends to use
in RHEL cases, the behavior is still undetermined (or it will use a different rule, such as shorter names wins
kernel-devel-uname-r is supported down to el6/el7 kernels, I haven't checked el5 ones. All current fedora releases are supported.
The long term solution is probably to use boolean dependencies, and that's should fix the behavior to install the right kernel*devel varriant matching the kernel*.
That been said, it will not check that the "version" are same...
Fixed upsteam in commit 19eace0:
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
This change is available in current release.