Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1515386 - "dnf history info" output unclear on which package is obsoleting the "obsoleted" ones
Summary: "dnf history info" output unclear on which package is obsoleting the "obsolet...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-20 17:38 UTC by Jan Pokorný [poki]
Modified: 2019-04-12 17:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-12 17:37:38 UTC


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2017-11-20 17:38:58 UTC
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.

Comment 1 Fedora End Of Life 2018-02-20 15:31:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 2 Jaroslav Mracek 2018-09-24 17:35:46 UTC
Please can you test the latest dnf from our copr repository rpmsoftwaremanagement/dnf-nightly if output is better. Thanks a lot.

Comment 3 Jan Pokorný [poki] 2018-09-25 14:11:53 UTC
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).

Comment 4 Jaroslav Mracek 2019-04-12 17:37:38 UTC
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


Note You need to log in before you can comment on or make changes to this bug.