On Wed, 2007-07-25 at 17:55 +0200, Florian Festi wrote: > 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.
Florian, I looked through the diffs and there is just too much there to accept as one patch. When we first went to the internal depsolver I said: "we'll be able to get back a bunch of time b/c we won't have to do the lookups to compensate for the ts.check() result being that stupid NEVR tuple." In order to get to there we made a new object from the DepCheck that would hand us the already-resolved out package object and what it needed/conflicted with. That's what self._dcobj is. It's the DepCheck class. Instead of ripping out huge portions of the depsolver it would be better to take this a little at a time: 1. get rid of all the detection for figuring out where the requiring pkg is coming from: the _proccesReq bits. you did that - good. 2. change the options passed to requiringFromTransaction/requiringFromInstalled but nothing else. you did part of that but then went too far. 3. after we have a handle on what we're getting back from DepCheck and if it is sufficient on how to change things then we can work on refactoring the code down some. Otherwise we end up with another big jump in the depsolving code and figuring out where we regressed becomes difficult. I understand your desire to change things and make them happen "right now" but it makes it impossible to follow all the changes and that makes debugging much much harder for me. And since I'm having to sift depsolving issues in bugzilla I need to be sure I know where this code is going so I can answer better. So, in short, I need smaller chunks and smaller changes at a time to move forward. As an example depsolve.py is 1259 lines of code and your patch is 760 lines long. -sv _______________________________________________ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
