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.
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)
(the last one comes from a fortran include file)
Now, I could fix the shell script with a line like:
libdir=`rpm --eval %{_libdir}`and maybe fix the header files with a #ifdef (or equivalent for fortran). However, this seems like a bit much. And it doesn't cover other cases, like where a manpage, or README file may have a reference to %{_libdir} in it.
As such, it seems to me that there are valid cases where the files currently conflict that don't really strike me as a packaging bug. Is there a consensus in the rpm community about the "right" way to handle these cases? And if the packages should be changed, or if rpm should have a way to handle these cases? 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?
Thanks,
Sean
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
