On Sat, Dec 01, 2007 at 12:24:16AM +0100, Nagy Gabor wrote:
On Thu, Nov 29, 2007 at 10:13:42PM +0100, Nagy Gabor wrote:
OK, but I leave the benchmark for you;-) Note: Long "dependency paths" like in smoke001.py may cause notable slowdown. I made a quick "hack", so probably I made some mistakes...
I couldn't measure any difference. pacman always need ~3.5 seconds for running smoke001.
Because it is an add transaction;-) I just said that it contains a long dependency path, which can cause notable slowdown in case of -S first_element_of_path. (Unfortunately I cannot write such tricky pactests in python).
Oops, my bad. In my defense, it was a bit late :) But now, I'm slightly confused. How hard is it to edit smoke001 to do what you want? It looks like a totally trivial change to me. So I'm not sure I understood what you wanted.
From 3b8f21423035f7bf683494a8e369b6501be8e379 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> Date: Thu, 29 Nov 2007 21:55:55 +0100 Subject: [PATCH] Reduce the negligence of _alpm_resolvedeps
This is a not-to-commit patch NOTE: -Se is temporarily removed, because now resolvedeps doesn't have spkg param
What is really bad about this patch besides breaking -Se? Do you see a clean way of reimplementing it? Well, the way you didn't like earlier: http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=b0c064d59b8786a1e...
dependency-list == populate(populatedlist - oldlist)
The previous code did that, and you wanted to call recursively sync_prepare on dependency-list, right? I think that's why I didn't like it much. In my opinion, there is no need to worry much about -Se. Where is this option used anyway? If there are use cases for it, it probably only involes running -Se with one target. Not several targets with inter-dependencies. So this extreme corner case doesn't need to be supported. That is, sync1001 should still pass, but sync1002 doesn't need to.