Maybe I am not on the correct lists here, but I have a question / remark concerning packaging and the use of a library that is provided in different tastes, like a seriel and Message Passing Interface (MPI) one. I came across this problem when packaging my own libgpiv3 / libgpiv-mpi3 (recently accepted and uploaded). These libraries are used by the other packages gpivtools / gpivtools-mpi from a single upstream source (not yet available on Deb). When testing the packaging of gpivtools(-mpi) with pbuilder it only can be done if libgpiv3 and libgpiv-mpi3 are to be installed simultaneously. Otherwise the building of one of the packages gpivtools / gpivtools-mpi is impossible. While working on the packaging of gpivtools(-mpi) I am getting across a similar problem with other libraries that are available in seriel and -mpi (libhdf5-serial-dev libhdf5-openmpi-dev to be more specific). Only one of these can be installed at once. As I also work with Paraview, which depends on libhdf5-openmpi, packaging and the use of gpivtools (that depends on libhdf5-dev) is impossible. (It is preferred to have the dependancy on libhdf5-dev, even in gpivtools-mpi as the .h5 files are quite small and don't need to be stored/retrieved in parallel way.) My question is why isn't it possible to package such libraries in a way they can be installed simultaneously? Am I doing something wrong here? If not, a suggestion might be to provide this possibility by filing a 'feature request' bug against all -mpi libraries. If this really is a weak point in packaging such libs, shouldn't it become a formal packaging policy? Just my thought, -- Gerber van der Graaf http://gpiv.sourceforge.net GnuPG key fingerprint: BF0A BBFE 5623 9761 C9E1 7C82 8B08 F586 D39A 2B64
Attachment:
signature.asc
Description: This is a digitally signed message part