In regard to: Multiarch question, Sean Dilda said (at 5:01pm on Feb 25, 2005):
I have a question on how multiarch rpm is supposed to work. I'm told by those who understand rpm better than me, that if you try to install the x86 and x86_64 versions of a package on a x86_64 box that they will not conflict.
And that if they do conflict, there's a packaging bug.
I have a case where the i386 and x86_64 versions of an rpm have files that conflict with each other, but I don't believe there's a packaging bug. As such, I'd like some clarification on how multiarch packages should work.
The package in question is for mpich. One of the files in this package is a shell script, /usr/bin/mpicc. This shell script contains a reference to
where the mpich libraries are installed (%{_libdir}). The i386 package
has a line that reads:
libdir=/usr/lib
and the x86_64 version has a line that reads:
libdir=/usr/lib64
Since they're different, the packages have different md5sums, and thus conflict.
You can practically hear the crickets chirping in the background can't you? I think your question hasn't generated any discussion because many people don't know what the best approach is. It's not an easy problem.
In the specific case you're illustrating, is it possible to have a functioning mpicc with support for both ABIs installed? I mean, if libdir is hardcoded to either the 32 bit ABI version or the 64 bit ABI version right in the script, you really only have a choice of having one or the other flavor (ABI) working at once, correct?
mpicc would be more packaging-friendly if it instead sourced a configuration file that set these, and if one could select which ABI to compile against using a command-line flag to mpicc, similar to how ABI-selection is done with most compilers.
Another case is that mpich customizes some header files for the platform its on. As such, I get some differences like this:
-#define MPI2CPP_ATTR long
+#define MPI2CPP_ATTR int
and: - PARAMETER (MPI_OFFSET_KIND=4) + PARAMETER (MPI_OFFSET_KIND=8)
Packages that hardcode sized types like this are not very multi-ABI friendly, and are going to present packaging challenges no matter what packaging system you use.
Or if you should just separate out the shared libs into their own package and not worry about installing the other 32-bit packages on 64-bit machines?
That seems to be the approach that commercial vendors are taking with their packaging systems, for platforms that support multiple ABIs.
Tim -- Tim Mooney mooney@xxxxxxxxxxxxxxxxxxxxxxxxx Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
