On Thu, 2008-04-17 at 23:33 -0400, seth vidal wrote:
On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote:
On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
Sérgio Durigan Júnior wrote:
Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system.
Right. If there are 32/64 packages available, and they don't properly install/run, then that's generally considered a bug (that should be fixed).
Here is one:
# rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 libgcc.i386
# rpm -q --qf "%{name}.%{arch}\n" -f \ /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so gcc.x86_64
# ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1
i.e. an x86_64 package depending on an i386 package.
Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
I am trying to package a package which needs to build and run some bits "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) environment, but I haven't managed to get this working in mock.
try using yum 3.2.14 from rawhide with mock and remove the silly exclude that's in mock currently for x86_64 builds.
OK, this will likely resolve the "mock" part of this issue (yet untested), but leaves other parts unclear:
Which rpm "arch" and which package does the /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1 symlink belong to?
ATM, it is part of gcc.x86_86 and is a dangling symlink in "pure basearch" installs.
Should it (or even the whole m32 subdir) be part of an *.i386 package?
Or, conversely should /lib/libgcc_s.so.1 (clearly i386'ed) be part of a "multilib'ed" gcc.x86_64 package or libgcc.x86_64 package?
I don't know.
Ralf