When getting a picture about an issue observed with the newest dnf transaction, which coincidentally involved package obsoleting step (see [bug 1515357]), I noticed the link between "obsoleted" and "obsoleting" packages is lost. Observe: # dnf history info > [...] > Packages Altered: > [...] > Obsoleted platform-python-3.6.2-12.fc28.x86_64 @rawhide > Obsoleted platform-python-libs-3.6.2-12.fc28.x86_64 @rawhide > Obsoleted platform-python-six-1.11.0-1.fc28.noarch @rawhide > [...] > Upgraded python3-3.6.3-2.fc28.x86_64 @rawhide > Upgrade 3.6.3-3.fc28.x86_64 @rawhide > Obsoleting python3-3.6.3-3.fc28.x86_64 @rawhide > [...] > Upgraded python3-libs-3.6.3-2.fc28.x86_64 @rawhide > Upgrade 3.6.3-3.fc28.x86_64 @rawhide > Obsoleting python3-libs-3.6.3-3.fc28.x86_64 @rawhide > [...] > Upgraded python3-six-1.11.0-1.fc28.noarch @rawhide > Upgrade 1.11.0-2.fc28.noarch @rawhide > Obsoleting python3-six-1.11.0-2.fc28.noarch @rawhide > [...] You cannot really tell from the output above that what happened was that platform-python-libs-3.6.2-12.fc28.x86_64 was obsoleted with python3-libs-3.6.3-3.fc28.x86_64. It would be a different story if the output was semantically ordered, e.g.: > Obsoleted platform-python-3.6.2-12.fc28.x86_64 @rawhide > Obsoleting python3-3.6.3-3.fc28.x86_64 @rawhide > [...] > Obsoleted platform-python-libs-3.6.2-12.fc28.x86_64 @rawhide > Obsoleting python3-libs-3.6.3-3.fc28.x86_64 @rawhide > [...] > Obsoleted platform-python-six-1.11.0-1.fc28.noarch @rawhide > Obsoleting python3-six-1.11.0-2.fc28.noarch @rawhide This would increase usability of "dnf history" feature wrt. package obsoletion, even if it would possibly mean duplicated "Obsoleting" entries. It might be applicable for other relations as well, but mere upgrading is clear already, simply thanks to much tighter coupling between before-after pairs.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Please can you test the latest dnf from our copr repository rpmsoftwaremanagement/dnf-nightly if output is better. Thanks a lot.
Installed that dnf COPR (is `dnf` enough or is `--best --allowerasing` needed to update also some surrounding packages?). No obsoleting scenario observed so far, will keep an eye on that, hopefully there is something to come soon (keeping `needinfo` set).
I believe that the situation was improved with dnf-4.0.9. See outputs bellow. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: TestA noarch 1-1 updates 6.5 k replacing TestB.noarch 1-1 Transaction Summary ================================================================================ Install 1 Package ==================================================================================================== dnf history info Begin time : Fri Apr 12 17:33:01 2019 Begin rpmdb : 296:e7e8727a4d4b97b6f1ecb818d42eee9e8050e038 End time : Fri Apr 12 17:33:02 2019 (1 seconds) End rpmdb : 296:e097a8ae26f1e422712d6e8737b45a69dc8b47cc User : System <unset> Return-Code : Success Releasever : 29 Command Line : update -y Packages Altered: Install TestA-1-1.noarch @updates Obsoleted TestB-1-1.noarch @@System