My experience is that it only removes the “-devel" packages for a kernel when it also removes the kernel. If I manually remove a kernel, then the next “purge-kernels” will not remove the "-devel” package that I failed to manually remove.
The logic for purge-kernels seems to be:
Find any installed kernels that should be removed;
also remove associated “*-devel” packages.
Manually removing a kernel but not manually removing the corresponding "-devel" will leave that "-devel* behind.
I’m not sure whether this counts as a bug or a feature. I’m thinking that there might sometimes be reasons to retain the *-devel" but not the kernel.
I’m thinking that there might sometimes be reasons to retain the *-devel" but not the kernel.
There are two kinds of *-devel packages. One is specific to binary kernel (kernel-flavor-devel). These are removed by zypper. Another one is generic, not tied to particular binary kernel - kernel-devel. zypper removes the former and leaves the latter.
I think it is a bug because it was not the case before with separate purge-kernels utility, before switch to zypper. I certainly do not have kernel-devel versions since the very first TW installation. I checked purge-kernels on Leap 15 and it explicitly removes kernel-devel and kernel-source for which no binary kernels are present. We may argue whether it should do it, but for now it is regression.
I suspect somehow condition got reversed in zypper implementation - now it skips kernel-devel for which no corresponding binary kernel is installed.
# zypper se -si kernel
Loading repository data...
Warning: Repository 'Main Update Repository' appears to be outdated. Consider using a different mirror or server.
Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...
S | Name | Type | Version | Arch | Repository
i+ | kernel-default | package | 5.3.18-lp152.10.4 | x86_64 | (System Packages)
i+ | kernel-default | package | 5.3.18-lp152.11.3 | x86_64 | Main Repository
i | kernel-default-devel | package | 5.3.18-lp152.10.4 | x86_64 | (System Packages)
i | kernel-default-devel | package | 5.3.18-lp152.11.3 | x86_64 | Main Repository
i+ | kernel-devel | package | 5.3.18-lp152.10.4 | noarch | (System Packages)
i+ | kernel-devel | package | 5.3.18-lp152.10.3 | noarch | (System Packages)
i+ | kernel-devel | package | 5.3.18-lp152.10.1 | noarch | (System Packages)
i+ | kernel-devel | package | 5.3.18-lp152.4.4 | noarch | (System Packages)
i+ | kernel-devel | package | 5.3.18-lp152.4.3 | noarch | (System Packages)
i+ | kernel-devel | package | 5.3.18-lp152.11.3 | noarch | Main Repository
i | kernel-firmware | package | 20200107-lp152.1.1 | noarch | Main Repository
i | kernel-macros | package | 5.3.18-lp152.11.3 | noarch | Main Repository
i+ | nfs-kernel-server | package | 2.1.1-lp152.8.2 | x86_64 | Main Repository
i | purge-kernels-service | package | 0-lp152.3.1 | x86_64 | Main Repository
Yes, there are “kernel-devel” for which the corresponding “kernel-default-devel” has been removed.
I’m not sure how that happened. When removing kernels manually, I always removed both. Then I started using “zypper purge-kernels”, and I probably didn’t pay close attention then. Now I am relying on the service, and paying even less attention.
I’ll clean it up for now, then monitor what happens in future.
RPM allows file to be owned by several packages as long as file attributes are identical in each package. kernel-devel contains only (part of) kernel source tree which is not changed by rebuilding package.
For the kernel itself, version 5.3.18-lp152.10.3 was not removed by purge-kernels. Rather, it was removed by “zypper dup” during an update. Why didn’t that also happen to kernel-devel?
I think that rebuild of binary kernel RPM changes something (at least compile stamp or similar) which leads to conflict so older version is removed.
Well, sure, it’s for Leap 15.2 instead of Tumbleweed.
I looked at a Tumbleweed system, and saw the same thing. There were additional “kernel-devel” that had not been removed. And they all appeared to be cases where a newer recompile had been installed without removing the original. I’m not sure, but perhaps that’s also the case for the OP.
In any case, this is surely a bug somewhere. I’ll open a bug report later (unless I find an existing one).
I only see the problem with relatively recent kernels, from after the purge-kernels service was revamped.