Hide Forgot
The flex package produces a single rpm that contains both the flex binary and the flex libraries. However, this is a problem on systems with installations of libraries for multiple architectures. For instance, on my x86_64 desktop box, I only get the x86_64 flex rpm installed, and so only have /usr/lib64/libfl.a installed. I *don't* get /usr/lib/libfl.a installed, and so can't build, say, pam for i686 on my x86_64 box. I can't install both packages without getting a conflict over the common files (such as the flex program).
I have no problems installing both x86_64 and i386 flex packages alongside. Turns out rpm won't overwrite the /usr/bin/flex with the version from i386 package. The libraries are both in place however. [root@prdell ~]# cat /etc/redhat-release Fedora Core release 5 (Bordeaux) [root@prdell ~]# rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' flex flex-2.5.4a-41.fc5.x86_64 flex-2.5.4a-41.fc5.i386 [root@prdell ~]# ls -ls /usr/lib*/libfl* 8 -rw-r--r-- 1 root root 2764 Jul 19 06:51 /usr/lib64/libfl.a 8 -rw-r--r-- 1 root root 2288 Jul 19 06:49 /usr/lib/libfl.a [root@prdell ~]# rpm -q --whatprovides --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' /usr/lib/libfl.a flex-2.5.4a-41.fc5.i386 [root@prdell ~]# rpm -q --whatprovides --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' /usr/lib64/libfl.a flex-2.5.4a-41.fc5.x86_64 The binary is owned by x86_64 package, so it will get removed on rpm -e even when i386 package is still in place, but installing and uninstalling i386 package alongside x86_64 is possible. I don't think it's necessary to have separate package for libfl.a. Is this OK for you?
Hmmm... You're right: it does work. Shouldn't the installation raise a complaint? For flex this probably isn't a problem, provided you install the right arch package first. So it's probably okay - at least I can't think of a problem with it just at this moment in time.
I believe this is by design of some internal rpm magic. I think it would complain e.g. if the two arches got different FlexLexer.h, or if there was real conflict in library files, but binaries probably get resolved by prioritizing x86_64 files.