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 How reproducible: dnf install systemtap-devel Actual results: kernel-devel-debug is installed (which might be right for systemtap, but not if using the regular kernel package) Expected results: it should install the kernel-devel matching the kernel (or at least the statistically best candidate). Additional info: 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: https://fedoraproject.org/wiki/Packaging:WeakDependencies So that would ends to use Requires: kernel-devel-uname-r %{fedora:Suggests: kernel-devel} 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: <https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=19eace0c06aefa21604f5ba4a5d9781e359a07c3;hp=e239d05087dc7fff26d50a3b17bdf15d97e33662>
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.