Most packages that were built in the incorrect way were documentation, but some others were written in Interpreted languages. (like Python)

Double-No: (1) Many documentation packages are probably really architecture independent, but if architecture dependent binaries were built from the same source package, the documentation package is archictecture dependent, too, for purely practical reasons. This is especially the case for all gtk-doc packages. (2) Python modules are not noarch! Marking them as noarch is one of the most frequent mistakes made by third party packagers. To find out if a package is noarch, do *not* ask yourself "is it written in an interpreted language" - ask yourself "will the unmodified RPM work on all architectures". For Python modules, the answer to this question is "no".

One example of interpreted language package that is i586 but should be noarch is : "eric" IDE

No! Look at the file list of the eric package: /usr/bin/eric3 /usr/bin/eric3-api /usr/bin/eric3-doc /usr/bin/eric3-helpviewer /usr/bin/eric3-qregexp /usr/bin/eric3-re /usr/bin/eric3-trpreviewer /usr/bin/eric3-uipreviewer /usr/bin/eric3-unittest /usr/lib/python2.4/site-packages/eric3 /usr/lib/python2.4/site-packages/eric3/APIs /usr/lib/python2.4/site-packages/eric3/APIs/python.api /usr/lib/python2.4/site-packages/eric3/APIs/qt.api /usr/lib/python2.4/site-packages/eric3/APIs/qtaxcontainer.api /usr/lib/python2.4/site-packages/eric3/APIs/qtcanvas.api /usr/lib/python2.4/site-packages/eric3/APIs/qtext.api /usr/lib/python2.4/site-packages/eric3/APIs/qtgl.api /usr/lib/python2.4/site-packages/eric3/APIs/qtnetwork.api /usr/lib/python2.4/site-packages/eric3/APIs/qtsql.api /usr/lib/python2.4/site-packages/eric3/APIs/qttable.api /usr/lib/python2.4/site-packages/eric3/APIs/qtui.api /usr/lib/python2.4/site-packages/eric3/APIs/qtxml.api /usr/lib/python2.4/site-packages/eric3/Checks /usr/lib/python2.4/site-packages/eric3/Checks/SyntaxCheckerDialog.py /usr/lib/python2.4/site-packages/eric3/Checks/SyntaxCheckerDialog.pyc /usr/lib/python2.4/site-packages/eric3/Checks/SyntaxCheckerForm.py /usr/lib/python2.4/site-packages/eric3/Checks/SyntaxCheckerForm.pyc /usr/lib/python2.4/site-packages/eric3/Checks/Tabnanny.py /usr/lib/python2.4/site-packages/eric3/Checks/Tabnanny.pyc /usr/lib/python2.4/site-packages/eric3/Checks/TabnannyDialog.py [...] As you can see, all the Python modules are installed in "/usr/lib/python2.4/site-packages". And now, where is the site-packages directory on x86_64? It's in "/usr/lib64/python2.4/site-packages". Therefore the unmodified RPM will *not* work on x86_64, and that's why the package has to be architecture dependent even though Python is an interpreted language. By the way, even pure shell scripts can be architecture specific if they hardcode "/usr/lib" or "/usr/lib64" somewhere. I think it's quite a good opportunity to point that out here once and forever, to improve the quality of third party packages for SUSE Linux. Right now there are many, many pseudo-noarch Python packages from third party repositories out there that simply don't work on x86_64. As far as it concerns your examples of documentation packages: I had a quick look over the list and am very sure that most of them are built from architecture dependent source packages. To be honest, I don't think that more than maybe a handful of packages in SUSE Linux are really incorrectly marked as architecture specific. -- Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer