Gijs Hollestelle wrote:
...
However there is a fourth step that I can not follow just by reading the patch:
It yanks out a lot of stuff from _processReq. Thereby simplifying it a
lot, however I see no argumentation why your new (much smaller and
simpler code) does exactly the same. Are you sure that all the tests
you removed where never being triggered and that there are no corner
cases that break because of this?
Yeah, there is a bit of background knowledge required to understand why this
is possible. I didn't mention it it the mail because it was in an earlier
"What I plan to do" mail.
The code removed tries to find the package object that matches the pkgtup
returned by the transaction check. This means it has to search the rpmdb and
the transaction to find the right one. Depending on where the package was
found it calls either _requiringFromTransaction or _requiringFromInstalled.
As the transaction check now returns the package object all the searching is
no longer needed. Querying po.repo.id != "installed" is probably a bit
touchy to tell where the package object comes from. May be it should be
reinforced/replaced by the class check.
This "What are you from" topic is relevant at some other places, too. I
haven't found the official yum policy for it yet but it will be more and
more important as we move away from pkgtup searches. May be someone can
point that out.
BTW I performed some testing using a test repo that I created filled
with 100 packages with random requirements, provides, etc. And it
appears that ffesti with just the first patch applied returns the same
results as the current upstream yum (when both are patched with a
small patch to always resolve deps alphabetically instead of semi
random order returned by calling unique on the array) so there appears
to be a valid reason for removing all that code from processReq I just
don't see it yet ;-)
I hope it is now clear why it works.
Are your test scripts available online somewhere? We really need more test
cases.
The full Depsolve patch set returns different results which (in my
first analysis) appear to be due to a change in the way that the
dependencies are resolved: upstream yum first gathers all requirements
for a depsolve phase and then solves them all together while ffesti
does it per package in the depsolve phase. This can yield different
resolve paths especially when there are multiple choices to resolve a
requirement.
This is more or less expected. Purpose of that patch is to alter the way
problems are processed. Conflicts and requirements to removed files are now
checked outside of the requirements loop. This is where the speed up comes
from. As yum doesn't make any guarantees about what packages are selected or
what problems are solved first this behavior change should be OK.
Thank you for taking care!
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
