Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-14 Thread Florian Festi
Jeremy Katz wrote: On Mon, 2007-06-11 at 17:49 +0200, Florian Festi wrote: _checkFileRequires: Ok, that's the difficult one... Rational between that method is that there are much more files that there are file requires. So it trades the number of files within the removed pkgs for the number

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-11 Thread Florian Festi
Jeremy Katz wrote: On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: * new _checkInstall, _checkRemove, * dropped _provideToPkg and _requiredByPkg * _checkConflicts, _checkFileRequires - work globally * ignoring installed problems and problems in updates properly? Have to

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-07 Thread Tim Lauridsen
seth vidal wrote: On Wed, 2007-06-06 at 10:24 +0300, Panu Matilainen wrote: On Tue, 5 Jun 2007, Jeremy Katz wrote: The other thing that would be nice (and you alluded to below) would be actually splitting into a patch series. As it stands right now, it's a good sized diff and it's

hg and branches (Re: [Yum-devel] [Patch] Resolver Performance and Correctness)

2007-06-07 Thread Charlie Brady
On Thu, 7 Jun 2007, Tim Lauridsen wrote: I have tried bot hg and git, hg seams easier to use at first look, but tools like Cogito[1] makes git easier to use. both ones will be fine with me. What troubles me a little, is the warning Jesse[2] sent about hg. Tim [1] : http://git.or.cz/cogito/

Re: hg and branches (Re: [Yum-devel] [Patch] Resolver Performance and Correctness)

2007-06-07 Thread Jesse Keating
On Thursday 07 June 2007 13:37:04 Charlie Brady wrote: AIUI, hg doesn't really need to elegantly deal with lots of branching. You fork a clone of the repo, then merge patch sets from one to the other as you wish. When you have a central system for managing the source, creating new repos is

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Florian Festi
Florian Festi wrote: Hi! I put together my patches in my own working dir (as proposed by James Bowes ;)= ) to see if they have the expected performance gain and if they fit together. It turned out that the performance gain is within the expected range and that it is possible to achieve that

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Florian Festi
Jeremy Katz wrote: On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: * TransactionData.removedmembers - used in _mytscheck to treat removed INSTALL members as Removes and removed REMOVE members as installs I'm not quite clear on what exactly this is trying to solve...

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Florian Festi
Jeremy Katz wrote: On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: * TransactionData.relatedto and .depends_on converted to sets Should be fine. This is the sort of thing that becomes a lot easier to integrate with separated out patchsets :) Jeremy Ok, this also contains a

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Florian Festi
Jeremy Katz wrote: On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: * added local rpms to pkgSack via localSack (cli.py) Hrmm... what are you trying to accomplish with this? Other API users are almost certainly not doing this Jeremy Reason for this is the way

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Florian Festi
Jeremy Katz wrote: On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: * whatProvides/Requires - returns {po - [matching Ps/Rs]} * added to PackageSackBase, MetaSack, PackageSack, YumAvailablePackageSqlite For consistency, it'd be better if these also took the aspo argument and

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Jeremy Katz
On Wed, 2007-06-06 at 11:11 +0200, Florian Festi wrote: Jeremy Katz wrote: On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: * TransactionData.relatedto and .depends_on converted to sets Should be fine. This is the sort of thing that becomes a lot easier to integrate with

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-06 Thread Panu Matilainen
On Wed, 6 Jun 2007, seth vidal wrote: On Wed, 2007-06-06 at 10:24 +0300, Panu Matilainen wrote: On Tue, 5 Jun 2007, Jeremy Katz wrote: The other thing that would be nice (and you alluded to below) would be actually splitting into a patch series. As it stands right now, it's a good sized

Re: [Yum-devel] [Patch] Resolver Performance and Correctness

2007-06-05 Thread Jeremy Katz
On Tue, 2007-06-05 at 13:22 +0200, Florian Festi wrote: I put together my patches in my own working dir (as proposed by James Bowes ;)= ) to see if they have the expected performance gain and if they fit together. It turned out that the performance gain is within the expected range and that