Dear fellow packagers, since our switch to noarch-capable python, a number of bugs for arch-dependent python module packages have popped up, where some module can't be imported even though it seems to be installed properly. Root cause of those bugs is common to all of them: half of the files are installed in platform-independent /usr/lib dir, while the other half goes into /usr/lib64 (on 64bits only, of course), causing all sorts of confusion. That is Bad Style (tm). Don't do it. in short: Fix your package so that it goes either into /usr/lib (in which case it should be noarch too), or into /usr/lib64. The bug will then go away. long version: In Python, the arch-independence is on a per-module level. Either the whole module is arch-independent, then it belongs to %python_sitelib, or some of it is arch-dependent and then the whole module belongs to %python_sitearch. Historically, sitelib and sitearch were in the same directory. Now that they are separate, two classes of problems have arisen. One, many python modules depend on being installed within a single directory. Sometimes explicitly and sometimes they make the assumption in some not-really-trivial way. There is even a feature called "relative imports" that relies on the fact that a whole module is installed in a single directory. Two, sometimes modules are not installed on python search path. Python doesn't search subdirectories automatically, so modules from e.g. %python_sitearch/gtk-2.0 can't be imported, even though modules from %python_sitearch itself can. For that reason, such module often installs a file.pth pointing to its directory. When python finds something.pth on its search path, it appends all directories listed in that file to the search path. Some packages install into two different locations but use only one pth file pointing into only one of them. Why is that a problem is left as an exercise for the reader. Distutils know all this and do the right thing, unless your upstream is extremely clever and installs two separate modules (wxGTK) or beats distutils into submission (egenix-mx-base). Also, prusnak volunteered and checked all packages in d:l:py that don't use --record-rpm, and they are all OK. hope this helps regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org