Bug 887317

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)

As you're showing all obsoletes instead of a single package, you might also want to throw in the SOLVER_TRANSACTION_SHOW_ALL flag.

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

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.

(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.

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.)

(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.

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).

Miroslav, this is fixed by dnf commit 44b8016 and will be included in dnf-0.3.4. Thanks for the report.

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

(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.)

(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.

> 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.

> 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.

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.