Description of problem: I believe drakrpm do not yet handle new naming sheme, at least with mixed packages of old/new scheme? Add fix to drakrpm, or can package conflicts fix this? Version-Release number of selected component (if applicable): rpmdrake-6.32-2.mga9 Steps to Reproduce: Currently as an example: 1. Already installed kernel-devel packages: $ rpm -qa | grep kernel | grep devel kernel-linus-devel-6.5.11-2.mga9 kernel-desktop-devel-6.5.11-5.mga9 kernel-desktop-devel-6.4.16-3.mga9 kernel-desktop-devel-6.5.13-2.mga9-1-1.mga9 kernel-linus-devel-6.5.13-1.mga9 kernel-desktop-devel-latest-6.5.13-2.mga9 kernel-desktop-devel-6.5.13-1.mga9-1-1.mga9 2. in drakrpm, choose show all updates, and pick kernel-desktop-devel-6.5.13-1.mga9.x86_64.rpm, execute. 3. Failure popup message, but for more completeness, I take the output from the terminal from where i started drakrpm: installing kernel-desktop-devel-6.5.13-1.mga9.x86_64.rpm from /var/cache/urpmi/rpms starting installing packages created transaction for installing on / (remove=0, install=1, upgrade=0) Installation failed: file /usr/src/kernel-6.5.13-desktop-1.mga9/include/generated/compile.h from install of kernel-desktop-devel-6.5.13-1.mga9.x86_64 conflicts with file from package kernel-desktop-devel-6.5.13-1.mga9-1-1.mga9.x86_64 file /usr/src/kernel-6.5.13-desktop-1.mga9/include/generated/utsversion.h from install of kernel-desktop-devel-6.5.13-1.mga9.x86_64 conflicts with file from package kernel-desktop-devel-6.5.13-1.mga9-1-1.mga9.x86_64
CC: (none) => mageiatools
Why can some kernel-devel packages not be installed concurrently? But others can. And seem to depend on install order. $ LC_ALL=C sudo urpmi --test kernel-linus-devel-6.4.9-1.mga9.x86_64 A requested package cannot be installed: kernel-linus-devel-6.4.9-1.mga9.x86_64 (in order to keep kernel-linus-devel-6.5.11-2.mga9.x86_64)
Either versioned and nonversioned scheme can be installed aside, but not as the same exact version. Ditto for -latest. (I could try to use "even" numbering for updates_testing and "odd" numbering for backports testing).
CC: (none) => ghibomgx
Odd/even could be a creative and useful idea for future. As this is already out we need to write some nice explanation in errata. Please suggest a few lines here, and i will put it in errata :)
(In reply to Giuseppe Ghibò from comment #2) > Either versioned and nonversioned scheme can be installed aside, but not as > the same exact version. Ditto for -latest. mostly because the /usr/src/kernel-$(uname -r)/ is the same in both -devel files.
This fancy „naming scheme“is high level botched: .mga9-1-1.mga9.x86_64 Mageia is the first distri which managed to break deps by using self created naming schemes…
Keywords: (none) => FOR_ERRATA9
(In reply to sturmvogel from comment #5) > This fancy „naming scheme“is high level botched: .mga9-1-1.mga9.x86_64 > Mageia is the first distri which managed to break deps by using self created > naming schemes… It's not that fancy... it's that nobody noticed it before (i.e. that version was in the packjage name), but indeed was used from mga1 to mga8, and before it was used in mandriva, and was introduced to allow multiple kernel installed side by side, without removing or interfering each other. It's always been there. unversioned naming scheme (i.e. mga9 scheme) used the possibility of RPM to have multiversioned packages, but indeed this is having some side effect on urpmi, especially on installing older versions.
Yes it is the mix that may cause problem for our tools. We need to shortly explain why, and how to get around easily. - also for less experienced users - preferably using our graphical tools only.
Entered under https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools: {{Bug|32626}} Kernels and their devel packages in backport repository have another naming scheme, that may be problematic together with similar packages installed from normal updates due to same base name. --- I think the easiest workaround for the user to get past this is to uninstall th conflicting kernel and kernel-devel
Keywords: FOR_ERRATA9 => IN_ERRATA9