[Yum-devel] sparc64v complex updates
jch at thehaxbys.co.uk
Mon Apr 22 14:10:38 UTC 2013
On 22/04/13 14:36, James Antill wrote:
> 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.
The kernel is marked installonly, I was being sloppy.
>> 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
> 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.
I'll bear that in mind.
>> , another fix was to change
>> multiarchlist = rpmUtils.arch.getArchList(multicompat)
>> multiarchlist = self._archlist[1:]
>> which picks up the hack that inserts sparc64 into the result from
> This might be fine, if you did this change inside of getArchList().
I'm not entirely sure that that will fly any further, though. In this
particular case it was right but the general case seemed to be wrong.
It's all broken again at the moment though so I may revisit that.
>> 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.
I thought at much.
>> 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).
Ah, now that is interesting news. I'll look into that.
More information about the Yum-devel