On Wed, 2007-04-25 at 20:09 +0200, Gijs Hollestelle wrote: > On 4/25/07, Gijs Hollestelle <[EMAIL PROTECTED]> wrote: > > On 4/25/07, Jeremy Katz <[EMAIL PROTECTED]> wrote: > > > Okay, simpler case is cpio. > > > > > > What's happening is that I have multiple kernels installed. We > > > overwrite the kernel provs in goneprovs and thus only check with one of > > > their provides, not both. Which then leads to results which leave out > > > the fact that libraw1394 depends on the newer of the two kernels I have > > > installed. > > Good catch! > > > > I've updated the patch. Now instead of constructing goneprovs and > > gonefiles as dicts with goneprovs[name] = prov > > I do goneprovs[prov] = 1 and when we need the name we get it as > > prov[0] this avoids the issue you mentioned and probably saves a few > > bytes of memory as well ;-) > Looks like I jumped the gun there.. there was a reason the hash was > built up as it was.. > > I did it the right way now, goneprovs[name] is now a list of provs. So > in the kernel case goneprovs[kernel] will be ['prov1','prov2'].
This still looks like it's going to be overwriting previous values in one or two cases. And with dicts of lists and all the overhead of checking for existence, etc I suspect that much of the speed gain (I wasn't seeing a whole lot) is going to go away. Given some of the other places we're still making substantial speed gains, I suspect that this isn't that productive of a path really... Jeremy _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
