On Thu, Mar 25, 2010 at 9:38 PM, Jonathan Conder j...@skurvy.no-ip.org wrote:
Hi again
I like this patch. Sometimes (-Sp, for example) it is needless to
compute this info, so this little speed-up is one more minor argument
for on-demand download-size computing.
Glad to hear it.
I also
On Wed, 2010-05-05 at 11:47 -0500, Dan McGee wrote:
I think you broke something unintentionally, see this commit:
6d79ba2db0f37f46b925a509ef83724fc0f61184
You completely removed the loop in _alpm_sync_prepare that makes sure
we have a filename for each participating package. Does that still
Thanks to Dan for pointing out a mistake I made.
---
lib/libalpm/db.h |3 ++-
lib/libalpm/sync.c | 14 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/lib/libalpm/db.h b/lib/libalpm/db.h
index 9b78ad4..1851b5c 100644
--- a/lib/libalpm/db.h
+++
Thanks to Dan for pointing out a mistake I made.
Personally I prefer the old patch over this. If I read this patch
correctly, you have completely removed the on-demand computation from
current pacman GUI. The old patch was better for -Sp for example...
I think we should catch the
On Wed, 2010-05-05 at 18:18 -0500, Dan McGee wrote:
Looks good now, except for one other mistake that I've fixed already
locally but I should point out to you- the patch doesn't even compile.
:) You tried treating a list pointer as a package object directly
rather than get the data pointer off
Hi again
I like this patch. Sometimes (-Sp, for example) it is needless to
compute this info, so this little speed-up is one more minor argument
for on-demand download-size computing.
Glad to hear it.
I also came up with these two possible solutions earlier, see 5. here:
Hi
Here is a patch to resolve FS#18769. I created a new INFRQ/infolevel to
describe package download size, so that it could be lazily calculated
like most of the other package info. This differs slightly from most of
the other infolevels, which correspond to information actually read by
