development packages and multilib

Tom Lane tgl at
Mon Apr 20 00:48:53 UTC 2009

=?iso-8859-1?q?Bj=F6rn_Persson?= <bjorn at> writes:
> I know that compiled libraries can be installed in both 32-bit and 64-bit 
> versions at the same time, but is this required for -devel packages as well? 

Yes, up to a point.  I am not sure if recent Fedora versions have
improved on matters (there was talk of improvement awhile back --- eg  But the
way it works for RHEL packages is that multilib conflicts are only
allowed for binary executable files, and I think only if they're in
standard locations such as /usr/bin, /sbin, etc.  For example, if your
-devel package has to install /usr/include/mypackage.h, then the 32-bit
and 64-bit versions must install *identical* copies of that file.

Now if mypackage.h comes straight from the upstream distro, this is
no problem.  For files generated during build (think mypackage-config.h)
it is a big problem, since such files often contain arch-specific
values.  The standard workaround is to install the actual generated
file as, say, /usr/include/mypackage-config-i386.h or
/usr/include/mypackage-config-x86_64.h, and have both packages provide
a textually identical stub file /usr/include/mypackage-config.h that
#include's the right one of these depending on platform #define's.

Actual library files of course aren't a problem since they are under
either /usr/lib or /usr/lib64.

The other common source of conflicts is generated configuration scripts,
eg "/usr/bin/mypackage-config".  The /usr/bin exception I mentioned
above applies only for *binary* executables --- if your package builds a
shell script or something similar that contains configuration values,
it still breaks the rules.  This can be solved with a similar
indirection workaround.  I tend to put the actual generated script
under /usr/lib or /usr/lib64, and then /usr/bin/ has a stub that
invokes the right one of these.

I'm not entirely sure what's the point of this rule, given that if you
have any binary executables the two packages aren't going to be
concurrently installable anyway.  But I suppose a lot of -devel packages
don't need to do that.

You can find examples of how I do this in the mysql and postgresql
package specfiles in CVS.  That stuff is all several years old now,
and there might be better ways that have evolved in the meantime
(especially if you only care about recent Fedora releases).
I'd be interested to find out more about how other people do it.

			regards, tom lane

More information about the fedora-devel-list mailing list