Bug 517616
Summary: | [atlas] atlas-sse instead of atlas-sse2 gets installed on SSE2 capable system | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Joachim Frieben <jfrieben> |
Component: | atlas | Assignee: | Deji Akingunola <dakingun> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 12 | CC: | dakingun |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-07-26 18:39:37 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: |
Description
Joachim Frieben
2009-08-15 08:05:08 UTC
I don't understand how this can happen, can you provide more information about what is actually pulling in atlas during installation. BTW, I also think this must be anaconda or yum issue rather than atlas packaging bug. # yum install numpy Loaded plugins: refresh-packagekit Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package numpy.i686 0:1.3.0-6.fc12 set to be updated --> Processing Dependency: libatlas.so.3 for package: numpy-1.3.0-6.fc12.i686 --> Processing Dependency: libptcblas.so.3 for package: numpy-1.3.0-6.fc12.i686 --> Processing Dependency: liblapack.so.3 for package: numpy-1.3.0-6.fc12.i686 --> Processing Dependency: libptf77blas.so.3 for package: numpy-1.3.0-6.fc12.i686 --> Running transaction check ---> Package atlas-sse.i686 0:3.8.3-9.fc12 set to be updated --> Finished Dependency Resolution Package numpy is installed by default when using the live CD. It appears that the dependency on atlas gets established only indirectly through the shared libraries. Looking at package names by alphabetical order, atlas-sse precedes atlas-sse2 and gets pulled in which understandable. I wonder whether packages atlas-sse2 or atlas-sse3 do get pulled in automatically on **any** system capable of taking advantage them. Other systems of mine are a Pentium III-M system for which atlas-sse is the right one. A further Opteron based system simply has package atlas installed which is more or less ok because on x86_64 systems, SSE2 is enabled at the compiler level. However, atlas-sse3 would have to be pulled in by hand, too. This raises the interesting question how to handle this package selection issue if it were possible at reasonable cost .. Likewise, on a Pentium III-M system, package atlas instead of atlas-sse gets pulled in during install from the current "rawhide" tree. Now that there is a base package atlas for Fedora 11/12 i[5/6]86 (see bug 510498) is there agreement that the decision of choosing the most efficient subpackage atlas-sse, atlas-sse2, .. be up to the user? In this case, I would close the bug as WONTFIX. (In reply to comment #3) > Likewise, on a Pentium III-M system, package atlas instead of atlas-sse gets > pulled in during install from the current "rawhide" tree. Now that there is a > base package atlas for Fedora 11/12 i[5/6]86 (see bug 510498) is there > agreement that the decision of choosing the most efficient subpackage > atlas-sse, atlas-sse2, .. be up to the user? Essentially, yes. > In this case, I would close the bug as WONTFIX. This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |