Re: [Yum-devel] [PATCH 2/3] UI for merged transactions in "history info".

2010-09-24 Thread Tim Lauridsen
On Fri, Sep 24, 2010 at 4:21 PM, James Antill wrote: > Eg. yum histry merge 1..2 => Will show the first two transactions > as though they were a single transaction. All the complicated bits > are in YumMergedTransaction.merge(), this is just a UI patch. > Adds this to the man page. > > Al

Re: [Yum-devel] [PATCH 1/3] Add dropCachedDataPostTransaction() API and document dropCachedData().

2010-09-24 Thread Tim Lauridsen
On Fri, Sep 24, 2010 at 11:31 PM, seth vidal wrote: > On Fri, 2010-09-24 at 00:02 -0400, James Antill wrote: > > Calling dropCachedData() before we are "done" is pretty bad, as we can > > load a package more than once. It's also a giant perf. hit, esp. for > > yumdb checksum*. So we Document all t

Re: [Yum-devel] [PATCH 1/3] Add merged history API, this is a combined history for multiple history transactions within a single object. The trans_data member is pretty tricky, so there is a bunch of

2010-09-24 Thread seth vidal
On Fri, 2010-09-24 at 10:21 -0400, James Antill wrote: Conditional ACK - on adding docs to the yum history page in the yum wiki -sv ___ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel

Re: [Yum-devel] [PATCH 1/3] Add dropCachedDataPostTransaction() API and document dropCachedData().

2010-09-24 Thread seth vidal
On Fri, 2010-09-24 at 00:02 -0400, James Antill wrote: > Calling dropCachedData() before we are "done" is pretty bad, as we can > load a package more than once. It's also a giant perf. hit, esp. for > yumdb checksum*. So we Document all that and add a special API to call > just after a transaction

[Yum-devel] [PATCH 1/3] Add merged history API, this is a combined history for multiple history transactions within a single object. The trans_data member is pretty tricky, so there is a bunch of tes

2010-09-24 Thread James Antill
pkgA-1 => pkgA-2 pkgA-2 => pkgA-3 pkgB-1 => pkgB-2 pkgB-2 => pkgB-1 ...becomes: pkgA-1 => pkgA-3 pkgB-1 => pkgB-1 (reinstall) ...note that we just give up if "impossible" things happen, Eg. pkgA-1 => pkgA-2 pkgA-4 => pkgA-5 ..

[Yum-devel] [PATCH 3/3] Fix installonly installs and "broken" rpmdbv stuff from tracebacks

2010-09-24 Thread James Antill
--- test/merge-history-transactions-tests.py | 71 +- yum/history.py | 23 +++--- 2 files changed, 76 insertions(+), 18 deletions(-) diff --git a/test/merge-history-transactions-tests.py b/test/merge-history-transactions-tests.py inde

[Yum-devel] [PATCH 2/3] UI for merged transactions in "history info".

2010-09-24 Thread James Antill
Eg. yum histry merge 1..2 => Will show the first two transactions as though they were a single transaction. All the complicated bits are in YumMergedTransaction.merge(), this is just a UI patch. Adds this to the man page. Also changes transaction time to have minutes/hours/days. Also

[Yum-devel] [PATCH 2/3] Remove the bad dropCachedData() calls. Use dropCachedDataPostTransaction(). This is a major speedup, and fixes some weird bugs with lookups giving back different packages than

2010-09-24 Thread James Antill
Move futureRpmDBVersion() to be before we need the checksums in history. Always calc. the new simpleVersion() ... as it's much cheaper now than when we next start (who runs without history anyway?:) --- yum/__init__.py | 18 +++--- 1 files changed, 11 insertions(+), 7 deletions(-)

[Yum-devel] [PATCH 1/3] Add dropCachedDataPostTransaction() API and document dropCachedData().

2010-09-24 Thread James Antill
Calling dropCachedData() before we are "done" is pretty bad, as we can load a package more than once. It's also a giant perf. hit, esp. for yumdb checksum*. So we Document all that and add a special API to call just after a transaction has run, to cleanup just the stuff we want. --- yum/rpmsack.p

[Yum-devel] [PATCH 3/3] Fix possible bug when "manually" setting checksum_type or checksum_data.

2010-09-24 Thread James Antill
We kind of got around this before by always reloading at the end of a transaction, so any bugs were limited until the next transaction performed. But now we almost always just use the index, so we should fix it. Basically just rm the cached version if anyone changes them, this is fine in a trans