Steps to Reproduce: 1. fresh install of mga7.1 using classic installer ISO, you may chose a small DE to save time. 2. boot it and verify it use the desktop kernel flavour. 3 upgrade to Mageia 8 per https://wiki.mageia.org/en/Mageia_8_Release_Notes#Upgrading_online.2C_using_DNF_.28CLI.29 4. See what kernel you use: server flavour. And you also have latest desktop kernel installed. Noted in https://wiki.mageia.org/en/Mageia_8_Errata#Upgrade_using_dnf In mailing list https://ml.mageia.org/l/arc/qa-discuss/2021-01/msg00542.html
CC: (none) => ngompa13Keywords: (none) => IN_ERRATA8
I'm taking a look at this now.
Status: NEW => ASSIGNEDAssignee: bugsquad => ngompa13
I can reproduce the issue, and I'm trying to figure out why it happens. I've also filed an upstream issue with libsolv, as I suspect that's where the issue is: https://github.com/openSUSE/libsolv/issues/433
Michael Schroeder has determined that this is caused by the kernel package obsoleting "crda". > The system has "crda" installed, and both kernel-server and kernel-desktop obsolete "crda". So it's handled like a package split. So this is a bug in the kernel packaging.
Summary: DNF dont select kernel flavour properly (at least not when upgrading Mageia) => kernels obsolete crda, triggering package-split installation behaviorAssignee: ngompa13 => tmbSource RPM: (none) => kernel-5.10.16-1.mga8.src.rpm
(In reply to Neal Gompa from comment #3) > Michael Schroeder has determined that this is caused by the kernel package > obsoleting "crda". > > > The system has "crda" installed, and both kernel-server and kernel-desktop obsolete "crda". So it's handled like a package split. > > So this is a bug in the kernel packaging. not really. as both server and desktop kernel satisfy the need of removing crda, they can both obsolete it. having only one of them obsolete it, it would mean installing desktop kernel on server system or the other way around... and urpmi has no problem what so ever getting it right...
(In reply to Thomas Backlund from comment #4) > (In reply to Neal Gompa from comment #3) > > Michael Schroeder has determined that this is caused by the kernel package > > obsoleting "crda". > > > > > The system has "crda" installed, and both kernel-server and kernel-desktop obsolete "crda". So it's handled like a package split. > > > > So this is a bug in the kernel packaging. > > not really. > > as both server and desktop kernel satisfy the need of removing crda, they > can both obsolete it. > > having only one of them obsolete it, it would mean installing desktop kernel > on server system or the other way around... > There's a much easier fix: use task-obsolete instead. That's what it's for. > and urpmi has no problem what so ever getting it right... Yes, libsolv's behavior *is* different. That doesn't make it *wrong*. I would argue that urpmi's behavior is wrong because it is applying on-system filters to obsoletes, making package splits weird. But that's beside the point: there are other ways to handle this obsoletion without involving multiversioned packages that do weird things.
(In reply to Neal Gompa from comment #5) > (In reply to Thomas Backlund from comment #4) > > (In reply to Neal Gompa from comment #3) > > > Michael Schroeder has determined that this is caused by the kernel package > > > obsoleting "crda". > > > > > > > The system has "crda" installed, and both kernel-server and kernel-desktop obsolete "crda". So it's handled like a package split. > > > > > > So this is a bug in the kernel packaging. > > > > not really. > > > > as both server and desktop kernel satisfy the need of removing crda, they > > can both obsolete it. > > > > having only one of them obsolete it, it would mean installing desktop kernel > > on server system or the other way around... > > > > There's a much easier fix: use task-obsolete instead. That's what it's for. > > > and urpmi has no problem what so ever getting it right... > > Yes, libsolv's behavior *is* different. That doesn't make it *wrong*. I and it does not make it *right* either...
(In reply to Thomas Backlund from comment #6) > (In reply to Neal Gompa from comment #5) > > (In reply to Thomas Backlund from comment #4) > > > (In reply to Neal Gompa from comment #3) > > > > Michael Schroeder has determined that this is caused by the kernel package > > > > obsoleting "crda". > > > > > > > > > The system has "crda" installed, and both kernel-server and kernel-desktop obsolete "crda". So it's handled like a package split. > > > > > > > > So this is a bug in the kernel packaging. > > > > > > not really. > > > > > > as both server and desktop kernel satisfy the need of removing crda, they > > > can both obsolete it. > > > > > > having only one of them obsolete it, it would mean installing desktop kernel > > > on server system or the other way around... > > > > > > > There's a much easier fix: use task-obsolete instead. That's what it's for. > > > > > and urpmi has no problem what so ever getting it right... > > > > Yes, libsolv's behavior *is* different. That doesn't make it *wrong*. I > > > and it does not make it *right* either... The documented RPM behavior for Obsoletes[1] is being followed here, so I would say no, libsolv's behavior is not wrong. > RPM removes all packages matching obsoletes of packages being installed, as it sees the obsoleting package as their updates. There does not have to be a one-to-one relationship between obsoleting and obsoleted packages. That indicates that if an Obsoletes relationship exists and multiple packages obsolete something, on upgrade it's *supposed* to do this. From that perspective, URPMI is *wrong*. [1]: http://rpm.org/user_doc/dependencies.html#obsoletes
(In reply to Neal Gompa from comment #7) > The documented RPM behavior for Obsoletes[1] is being followed here, so I > would say no, libsolv's behavior is not wrong. > > > RPM removes all packages matching obsoletes of packages being installed, as it sees the obsoleting package as their updates. There does not have to be a one-to-one relationship between obsoleting and obsoleted packages. > and here it states kernel packaging is not wrong either: "There does not have to be a one-to-one relationship..." > That indicates that if an Obsoletes relationship exists and multiple > packages obsolete something, on upgrade it's *supposed* to do this. From > that perspective, URPMI is *wrong*. No, It's just smarter on handling this than libsolv as it works as designed and does what we expect of it... > > [1]: http://rpm.org/user_doc/dependencies.html#obsoletes
(In reply to Thomas Backlund from comment #8) > (In reply to Neal Gompa from comment #7) > > > The documented RPM behavior for Obsoletes[1] is being followed here, so I > > would say no, libsolv's behavior is not wrong. > > > > > RPM removes all packages matching obsoletes of packages being installed, as it sees the obsoleting package as their updates. There does not have to be a one-to-one relationship between obsoleting and obsoleted packages. > > > > and here it states kernel packaging is not wrong either: > > "There does not have to be a one-to-one relationship..." > > > That indicates that if an Obsoletes relationship exists and multiple > > packages obsolete something, on upgrade it's *supposed* to do this. From > > that perspective, URPMI is *wrong*. > Yes, a one-to-many relationship is the "package split" behavior, and libsolv is working *exactly* as RPM specifies this behavior. > > No, It's just smarter on handling this than libsolv as it works as designed > and does what we expect of it... > This is still an incoherent behavior for URPMI because it means that package splitting behavior via Obsoletes is not reliable.
How does this work in Mageia 9, with the new naming scheme? I see errata 9 have currently same note as mageia 8 about this (because it was initially a copy)
Closing old per https://forums.mageia.org/en/viewtopic.php?t=14988#p87992 " https://bugs.mageia.org/show_bug.cgi?id=28272 does not occur, as there is no crda. You may close the bug as fixed (old). " Does not occur in Mageia 9.
Status: ASSIGNED => RESOLVEDResolution: (none) => OLD