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
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
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
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/
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
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
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...
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
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
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
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
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
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
13 matches
Mail list logo