Bug 220953
Summary: | [PATCH]: Add better support for the multitude of sparc arches | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dennis Gilmore <dennis> | ||||||
Component: | yum | Assignee: | Jeremy Katz <katzj> | ||||||
Status: | CLOSED UPSTREAM | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | tcallawa | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | sparc | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-01-03 18:13:55 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Dennis Gilmore
2006-12-29 15:42:07 UTC
Created attachment 144548 [details]
add sparc support
Does this actually work? Because it looks rather incorrect to me. :/ seems to work perhaps we shouldnt return sparc64 in the sparcv8 and sparcv9 list. it detects sparcv8 sparcv9 and sparcv9v properly Python 2.4.3 (#1, Oct 24 2006, 17:21:19) [GCC 4.1.1 20060802 (Red Hat 4.1.1-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import yum >>> yum.rpmUtils.arch.getArchList('sparc') ['sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparcv8') ['sparc64', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparcv9') ['sparc64', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparcv9v') ['sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparc64') ['sparc64', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparc64v') ['sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] Created attachment 144574 [details] Try to fix sparc handling This is the behavior we want: >>> import yum >>> yum.rpmUtils.arch.getArchList('sparc') ['sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparcv8') ['sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparcv9') ['sparcv9', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparcv9v') ['sparcv9v', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparc64') ['sparc64', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] >>> yum.rpmUtils.arch.getArchList('sparc64v') ['sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8', 'sparc', 'noarch'] This attached patch gives us this behavior. Note that I have to do an ugly hack in one place, because sparc64v needs to have both sparc64 and sparcv9v inherited, and python is only letting us get one. Someone with more python skill than me could probably figure out the right way to get the proper chaining without this hack. (sparc64 doesn't get sparcv9v, and sparcv9v doesn't get sparc64, but sparc64v gets both) Now, to be fair, I'm still not sure I have this 100% right: bash-3.1# python Python 2.4.3 (#1, Oct 25 2006, 12:47:51) [GCC 4.1.1 20060802 (Red Hat 4.1.1-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import yum >>> yum.rpmUtils.arch.getBestArchFromList(["sparc64v","sparc64","sparcv9v","sparcv9"]) 'sparc64v' >>> bash-3.1# sparc32 python Python 2.4.3 (#1, Oct 25 2006, 12:47:51) [GCC 4.1.1 20060802 (Red Hat 4.1.1-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import yum >>> yum.rpmUtils.arch.getBestArchFromList(["sparc64v","sparc64","sparcv9v","sparcv9"]) 'sparcv9v' Is this what we want it to say in the default case? (user types yum on a sparc64 system). I'm not sure. When y'all get this sorted as to how you think it should be, let me know, okay? spots way is correct Committed spot's patch upstream on HEAD and 3.0.x so it'll be in 3.0.3 which will likely be out the end of the week. |