=?iso-8859-1?q?Bj=F6rn_Persson?= <bjorn@xxxxxxxxxxxxxxxxxxxx> 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 https://fedoraproject.org/wiki/BillNottingham/MultilibDraft). 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
