Calling sortUpgrades from install.py -- shouldn't it be sortInternalRequires?

[Jan Pazdziora]

On Tue, May 15, 2007 at 10:57:03AM -0300, Gustavo Niemeyer wrote:
> 
> If you look at the implementation, you'll see that the policy provides
> a caching mechanism used by the transaction computing to avoid
> recomputing priorities over and over again. In this specific case, the
> caching isn't really important.

Gustavo, thanks. However -- can't the policy also provide some custom
getPriority which we will miss completely here?

> > - Why does the main function call sortUpgrades in the first place --
> >   shouldn't it be calling something like sortInternalRequires instead?
> >   If we install a list of packages (pkgs), why do we potentially also
> >   add packages that are being upgraded by pkgs?
> 
> We don't.. it's just sorting the list of matched packages do get the
> best choices. It's not mutating the list.

You're right. Still, what I've ended up seeing -- if I do an install
with just the package name and ctrl.search returns multiple records
with different versions, after the sortUpgrades, the older version
"bubbles up". These are packages that have obsoletes in them (and
these end up in .upgrades) pointing to some other packages that are
not part of that transaction.

Hmmm. I should probably try to create a simple reproducer rpms. The
packages I'm hitting these with are too complex / interlinked with
dependencies and obsoletes ...

-- 
Jan Pazdziora
Satellite Sustaining Engineering, Red Hat