[Yum-devel] small fix for marking more updates as simple ones

[Seth Vidal]

On Thu, 20 Aug 2009, Dimitrios Apostolou wrote:

> Hello list,
>
> while trying to understand and optimize doUpdates() (which is the next big 
> bottleneck) I realised that the majority of packages are marked as complex 
> updates. If I undestand correctly (great possibility that I don't though), 
> only multilib and multiarch packages should be complex. If so the next small 
> fix I think is valid:
>
>
> diff --git a/rpmUtils/updates.py b/rpmUtils/updates.py
> index 3ce1eba..b748366 100644
> --- a/rpmUtils/updates.py
> +++ b/rpmUtils/updates.py
> @@ -321,6 +321,9 @@ class Updates:
>             for (e, v, r) in newpkgs[(n, a)]:
>                 if (new_e, new_v, new_r) != (e, v, r):
>                     newpkgs[(n, a)].remove((e, v, r))
> +            for (a2, e, v, r) in newpkgs[(n, None)]:
> +                if (new_e, new_v, new_r) != (e, v, r) and a == a2:
> +                    newpkgs[(n, None)].remove((a2, e, v, r))
>
>
>         for (n, a) in newpkgs:
>
>
> It seems that line 364 - availarchs.append(a) - was being executed even for 
> package versions excluded in the previous step because newpkgs[(n,None)] 
> didn't only include latest versions. I think this fixes it.
>

complex updates are any update for which there is more than one arch 
available. It doesn't have to be multilib or multiarch.
for example:

glibc.i386, glibc.i686
foo.noarch, foo.i386

neither of those are multilib but they are complex updates.

I've not tested your patch yet but that is something to keep in mind.

-sv