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.
Thanks for the response.
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?
For my part, I think the correct version is to just have the 64-bit version of the script install on the x86_64 boxes, and the 32-bit version on the x86 boxes. The only reason I'd consider making the script capable of doing both ABIs is in order to make the md5sum match in the two packages as a way to work around this bug. (But then, I've never gone in for the idea of cross-compiling)
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.
Likewise, in this case, I'd just prefer that rpm install the 64-bit and ignore the 32-bit version. This is how it handles ELF files, I just wish it would handle other files that way. That, or allow an option in %files to request that the file be handled that way.
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.
Thanks. That's actually what I was considering doing before I was told that you should be able to install both arches of the package without conflicts.
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
