Hi!
I synced my personal repository to the new, shiny, yum git repository. The
web interface can still be found at:
http://www.jur-linux.org/git/?p=yum-ffesti.git;a=summary
It now contains tree branches:
* master - this is yum upstream
-> ffesti - this contains my search/depcheck changes
-> resolveDeps - experimental next step - see below
for testing you can "git clone git://www.jur-linux.org/git-data/yum-ffesti"
use "git branch -a" to see the branches and
"git checkout origin/ffesti" to switch to my "old" change set and
"git checkout resolveDeps" to switch back
As all the patches got moved around quite a bit please tell me if anything
breaks. I intend to continuously rebase these branches to yum head.
resolveDeps refactoring
=======================
I have to admit that I did not have a look into the depsolving part of the
Depsolver. After accelerating the depcheck code I was wondering why
performance still was not where it should be in the end. Some issues were
very obvious like calling the global checks (checkFilerequies,
checkConflicts) too often. So it was an natural step to break up _mytscheck
to get the Requirement checks into an own loop. This would also allow
changing the return values of the .check* methods to something less brain
dead - like package objects instead of NEVR tuples (yes, there is no A). It
turned out that the depsolving part of the depsolver is over complicated and
doing a lot of additional searches while trying to regain the information
that has been simply dropped by the depcheck code. Sadly this was necessary
in the part when yum was still using the rpmlib but now this doesn't make
sense anymore.
The current patch set is still experimantal. I moved out some code into
._update() to update pkgs to resolve problems. It is reused in the new
processConflict method where it is likely to fail. At a lot of other places
I used a chain saw to get the code roughly into right shape. So don't expect
something polished. I guess some callbacks and logging message are broke
especially the ones related to the depcheck loop that doesn't exist anymore.
Nevertheless performance has further increased. Here are the numbers in
comparison to the rpmlib based yum (3.0.3) an 3.2 branch yum similar to the
one shipped with F7 and pyrpm. New stats are in the last column.
Real time (seconds)
Operation | 3.0.3 | 07/05/07| pyrpm |07/07/24
--------------------------------------------------------------
Warmup: Full install | 653.51 | 1064.35 | 147.23 | 100.42
Resolve normal install | 40.59 | 134.11 | 8.04 | 12.14
Resolve full install | 477.67 | 1093.57 | 51.01 | 65.48
Resolve install [a-k]* | 313.56 | 887.40 | 33.52 | 46.84
Resolve empty update | 6.91 | 6.57 | 13.36 | 5.42
Resolve update libgnome | 3.34 | 2.57 | 7.51 | 5.67
Resolve big update | 33.04 | 45.56 | 24.81 | 14.69
Resolve erase glibc | 29.83 | 37.72 | 30.95 | 34.56
Warmup: Dist upgrade | 81.42 | 40.67 | 108.50 | 11.34
Resolve dist upgrade | 52.07 | 40.29 | 27.20 | 10.80
depcheck Refactoring
====================
Now that the git infrastructure is in place it is time to decide what to do
with my search/depcheck code. From my perspective there are only two minor
issues left:
* check if local rpms are detected correctly
* this is more or less a policy issue - do pkg objects have to be from
the existing pkg classes depending on their sources
* Check setAsDep() call in checkInstall
* I think the code is more correct than it was. May be someone wants to
speak up against that?
Main thing missing is a review for inclusion. Yeah, it's quite some code. If
someone wants to start I'd be glad to offer any help - be it about the code,
where to start or how to handle git. Any volunteers?
Florian
_______________________________________________
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
