[Yum-devel] sparc64v complex updates

James Antill james at fedoraproject.org
Mon Apr 22 13:36:27 UTC 2013

On Thu, 2013-04-18 at 17:08 +0100, John Haxby wrote:
> Hello All,
> I've been tinkering with a old sparc box recently and noticed an odd
> problem when yum updating the kernel.  If I have two kernels currently
> installed and use yum update to pick up a third, it's ignored.   Turning
> on debug shows that the new kernel is being put in a complex update, but
> nothing more is said.  The complex update code completely ignores it.

 So the first thing is ... kernels shouldn't be updating, as they should
be marked as installonly, so that makes me wonder if everything is setup
correctly anyway.

> I've tried three different fixes for this: tell getCanonArch() to return
> sparc64 instead of sparc64v (it's a little rack server than no one
> loved)

 So one problem is that sparc is pretty dead, and you might well be the
only person how cares about running yum on it. If something needs fixing
then pretending sparc64v == sparc64 might be the best solution.

> , another fix was to change
>     multiarchlist = rpmUtils.arch.getArchList(multicompat)
> to
>     multiarchlist = self._archlist[1:]
> which picks up the hack that inserts sparc64 into the result from
> getArchList().

 This might be fine, if you did this change inside of getArchList().

>   The actual fix I've settled on, for the moment, is
> attached and that is to put the same hack into the biarches list for the
> complex update.   However, going back through the history of this, I see
> that there was a time when the arches dict had two entries for sparc64v
> -- one mapping to sparc64, the other to sparcv9v (commit bce3a3c).   The
> code with the "hack hack hack" comment effectively does both (as does my
> attached patch).   I do wonder, though, if the wrong line was selected
> for deletion with commit bce3a3c.

 Having arch stuff outside of rpmUtils.arch is not going to get ACKd.
You could add a getBiarches() to the arch file and paste this fix there,
which is basically what you have now but will get ACKd.

> Alternatively, perhaps arches should map sparc64v to ['sparcv9v',
> 'sparc64'] which would make getArchList() much more interesting.

 This is the common way to fix these kinds of things (Eg. armv7l).

More information about the Yum-devel mailing list