Bug 887317 - Dnf should beter report upgrades via obsoletes.
Dnf should beter report upgrades via obsoletes.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ales Kozumplik
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 871892
  Show dependency treegraph
 
Reported: 2012-12-14 11:38 EST by Miroslav Suchý
Modified: 2014-09-30 19:40 EDT (History)
3 users (show)

See Also:
Fixed In Version: dnf-0.3.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-14 04:52:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2012-12-14 11:38:59 EST
Description of problem:
I just upgraded system and PackageKit-Qt replace PackageKit-qt. While yum report it as:

Instalování:
 PackageKit-Qt                                              x86_64                          0.8.6-3.fc18                                              fedora                                             67 k
     nahrazuje se  PackageKit-qt.x86_64 0.8.4-7.fc18


dnf report it as:
Instalování:
 PackageKit-Qt                                              x86_64                          0.8.6-3.fc18                                              fedora                                             67 k
Odstraňuje se:
 PackageKit-qt                                              x86_64                          0.8.4-7.fc18                                              @System                                             0

While dnf behaviour is not wrong per se. I think yum behaviour is better. And if it will not cause much problem it should be implemented.

Version-Release number of selected component (if applicable):
dnf-0.2.17-1.git6a055e6.fc18.noarch
Comment 1 Michael Schröder 2012-12-17 09:56:21 EST
Maybe that can be done by changing the hawkey code to:

Id type = transaction_type(trans, p, SOLVER_TRANSACTION_SHOW_ACTIVE | SOLVER_TRANSACTION_SHOW_OBSOLETES);
if (type == SOLSOLVER_TRANSACTION_OBSOLETES)
  type = SOLVER_TRANSACTION_UPGRADE;

(not tested, though)
Comment 2 Michael Schröder 2012-12-18 06:02:35 EST
As you're showing all obsoletes instead of a single package, you might also want to throw in the SOLVER_TRANSACTION_SHOW_ALL flag.
Comment 3 Fedora End Of Life 2013-04-03 09:36:11 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 4 Michael Schröder 2013-04-25 06:55:29 EDT
Current libsolv also supports SOLVER_TRANSACTION_OBSOLETE_IS_UPGRADE, so you just need to use

SOLVER_TRANSACTION_SHOW_OBSOLETES|SOLVER_TRANSACTION_SHOW_ALL|SOLVER_TRANSACTION_OBSOLETE_IS_UPGRADE

and everything should work.
Comment 5 Ales Kozumplik 2013-04-26 04:04:21 EDT
(In reply to comment #4)
> Current libsolv also supports SOLVER_TRANSACTION_OBSOLETE_IS_UPGRADE, so you
> just need to use
> 
> SOLVER_TRANSACTION_SHOW_OBSOLETES|SOLVER_TRANSACTION_SHOW_ALL|SOLVER_TRANSACT
> ION_OBSOLETE_IS_UPGRADE
> 
> and everything should work.

Now I'm wondering whether you've understood the bug (with Czech strings in comment 0, sorry) as the opposite of what the user wants: he wants the obsoletes to be explicitly shown as obsoletes, not upgrades.
Comment 6 Michael Schröder 2013-04-26 06:12:53 EDT
Well, I understood that a package rename should not be displayed as a "install of new name" and "erase of old name".

Currently hawkey only queries for SOLVER_TRANSACTION_UPGRADE.
Yum seems to have a "OBSOLETING" class, which seems to be missing in hawkey.

So you probably should just use
SOLVER_TRANSACTION_SHOW_OBSOLETES
and add a goal.list_obsoleting() function.

Note that SOLVER_TRANSACTION_SHOW_ALL says you'll show all obsoleted packages like yum does, hawkey also does not seem to have a method to query for all obsoleted packages.

(The tricky thing is that transaction_all_obs_pkgs() will contain all replaced packages, i.e. also packages with the same name. So an interesting test case is a new version of a package that now also obsoletes some other package, i.e. it's an Upgrade with an obsoletes. I don't think yum does that corrently.)
Comment 7 Ales Kozumplik 2013-04-26 06:56:24 EDT
(In reply to comment #6)
> Well, I understood that a package rename should not be displayed as a
> "install of new name" and "erase of old name".
> 
> Currently hawkey only queries for SOLVER_TRANSACTION_UPGRADE.
> Yum seems to have a "OBSOLETING" class, which seems to be missing in hawkey.
> 
> So you probably should just use
> SOLVER_TRANSACTION_SHOW_OBSOLETES
> and add a goal.list_obsoleting() function.
> 
> Note that SOLVER_TRANSACTION_SHOW_ALL says you'll show all obsoleted
> packages like yum does, hawkey also does not seem to have a method to query
> for all obsoleted packages.
> 
> (The tricky thing is that transaction_all_obs_pkgs() will contain all
> replaced packages, i.e. also packages with the same name. So an interesting
> test case is a new version of a package that now also obsoletes some other
> package, i.e. it's an Upgrade with an obsoletes. I don't think yum does that
> corrently.)

Ok, so we are actually on the same page. Yeah, I'm fixing it along the lines you're suggesting, I'll link the patch when it's ready and tested against the basic cases.
Comment 8 Ales Kozumplik 2013-04-26 09:47:20 EDT
In 56c79ed,

https://github.com/akozumpl/hawkey/commit/56c79ed62d46b60b663b5c85b711383af5d5901a

I'm adding methods functions to
a) see all the transaction's package's obsoletes and upgrades (through transaction_all_obs_pkgs())
b) see all the packages that are obsoleted in the transaction.

These two information can then be used to produce the DNF output like suggested in this bug, i.e. for each install/upgrade I can take a look at the intersection of the upgrading packages' obsoletes and all the transactions obsoletes and obtain the set of packages that are obsoleted (and not upgraded).

Also I'm thinking about changing the list_erasures() semantics to not report the obsoleted packages: RPM knows to erase them anyway and if the client is interested he can obtain the original set as a union of list_erasures() and list_obsoletes(). 

I'll also plan to remove hy_goal_package_obsoletes() (using transaction_obs_pkg()), I don't see benefits over using transaction_all_obs_pkgs() all the time (since even if I test whether the package returned by transaction_obs_pkg() has a different name as the transaction member, I can still miss further proper obsoletes given a package can obsolete more than one installed package).
Comment 9 Ales Kozumplik 2013-04-26 09:51:29 EDT
Miroslav, this is fixed by dnf commit 44b8016 and will be included in dnf-0.3.4. Thanks for the report.
Comment 10 Ales Kozumplik 2013-04-26 09:53:08 EDT
Sample CLI output now:

$ dnf upgrade vlgothic-fonts
Setting up Upgrade Process
Resolving Dependencies
--> Starting dependency resolution
---> Package vlgothic-fonts.noarch 20120325-1.fc17 will be upgraded
---> Package vlgothic-fonts-common.noarch 20120325-1.fc17 will be obsoleted
---> Package vlgothic-fonts.noarch 20121230-3.fc17 will be an upgrade
--> Finished dependency resolution

Dependencies Resolved

=====================================================================================================================
 Package                        Arch                   Version                         Repository               Size
=====================================================================================================================
Upgrading:
 vlgothic-fonts                 noarch                 20121230-3.fc17                 updates                 2.2 M
     replacing  vlgothic-fonts-common.noarch 20120325-1.fc17

Transaction Summary
=====================================================================================================================
Upgrade  1 Package

Total download size: 2.2 M
Installed size: 2.2 M
Is this ok [y/N]: N
Comment 11 Michael Schröder 2013-04-26 10:55:44 EDT
(Hehe, so you *do* show obsoletes as Upgrades instead of Installs like yum did.)

(So you didn't like old yum's TS_OBSOLETING state?)

Seems like you forgot about SOLVER_TRANSACTION_SHOW_ALL? If you install package A that obsoletes installed B and C, dnf will probably report that C is erased because libsolv thinks you're just listing B as being obsoleted. 

(Also please consider renaming hy_goal_list_obsoletes to hy_goal_list_obsoleted, as it only returns obsoleted packages. OTOH you plan to remote the method again anyway.)

(And downgrades can obsolete packages as well. Even reinstalls can obsolete packages.)
Comment 12 Ales Kozumplik 2013-04-29 02:48:41 EDT
(In reply to comment #11)
> (Hehe, so you *do* show obsoletes as Upgrades instead of Installs like yum
> did.)

I currently show obsoletes as 'replacing <package>', that's what yum does. So yes, I'm trying to emulate yum.

> (So you didn't like old yum's TS_OBSOLETING state?)

I don't like how the whole TransactionData in Yum works and will replace this class with something simpler and more flexible soonish.
 
> Seems like you forgot about SOLVER_TRANSACTION_SHOW_ALL? If you install
> package A that obsoletes installed B and C, dnf will probably report that C
> is erased because libsolv thinks you're just listing B as being obsoleted. 

Now I'm not following at all. I use transaction_all_obs_pkgs() so I should see both B and C as obsoletes no?

> (Also please consider renaming hy_goal_list_obsoletes to
> hy_goal_list_obsoleted, as it only returns obsoleted packages. OTOH you plan
> to remote the method again anyway.)

Yes, I will rename hy_goal_package_all_obsoletes() to hy_goal_package_all_obsoleted() instead.

> 
> (And downgrades can obsolete packages as well. Even reinstalls can obsolete
> packages.)

Hmm, true, will have to deal with that too.
Comment 13 Michael Schröder 2013-04-29 05:02:13 EDT
> I currently show obsoletes as 'replacing <package>', that's what yum does

No, I mean the section. DNF prints:

Upgrading:
 vlgothic-fonts [...]
     replacing  [...]
YUM prints:

Installing:
 vlgothic-fonts [...]
     replacing  [...]

> Now I'm not following at all. I use transaction_all_obs_pkgs()...

While it's true that transaction_all_obs_pkgs() will contain all obsoletes, not using SOLVER_TRANSACTION_SHOW_ALL will make libsolv think that you'll just print the "main" obsoleted package, and thus map all the other ones to erase.
Thus you'll get:

Upgrading:
  A [...]
    replacing B [...]
    replacing C [...]

Erasing:
  C [...]

You don't want C to be listed a second time.
Comment 14 Ales Kozumplik 2013-04-29 08:43:46 EDT
> No, I mean the section. DNF prints:
> 
> Upgrading:
>  vlgothic-fonts [...]
>      replacing  [...]
> YUM prints:
> 
> Installing:
>  vlgothic-fonts [...]
>      replacing  [...]

Ah, that's right. But it's actually an upgrade, there's an old vlgothic-fonts that's being upgraded (and then vlgothic-fonts-common is obsoleted/"replaced"). Not sure why yum reports it as 'Installing'.

> 
> > Now I'm not following at all. I use transaction_all_obs_pkgs()...
> 
> While it's true that transaction_all_obs_pkgs() will contain all obsoletes,
> not using SOLVER_TRANSACTION_SHOW_ALL will make libsolv think that you'll
> just print the "main" obsoleted package, and thus map all the other ones to
> erase.
> Thus you'll get:
> 
> Upgrading:
>   A [...]
>     replacing B [...]
>     replacing C [...]
> 
> Erasing:
>   C [...]
> 
> You don't want C to be listed a second time.

Ah, true. What I've been doing to keep the pre-56c79ed hawkey API intact (report obsoletes among erases) is to compare the sets of all obsoletes with all erases and not report those erases that are obsoletes. I'll try SOLVER_TRANSACTION_SHOW_ALL shortly.
Comment 15 Ales Kozumplik 2013-04-29 12:53:08 EDT
Using SOLVER_TRANSACTION_SHOW_ALL to have list_erasures() and list_obsoleted() always disjoint:

https://github.com/akozumpl/hawkey/commit/8d77592ad3f7ccf68e75e4f2dbf285d632bd098d

Since libsolv started reporting replacing installs (e.g. A obsoletes B but there's no old A installed) as obsoletes I changed the list_installs() function to merge them together, to keep things simple. Obsoleting upgrades are still reported as upgrades.

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