A start has been made already some time ago with this. See Debian bug #521221 libhdf5-openmpi-1.6.6-0: simultaneous installation of -serial and -mpi packages Gerber On Thu, 2009-04-30 at 10:11 +0200, Francesco P. Lovergine wrote: > On Sun, Apr 26, 2009 at 08:19:20PM +0200, Magnus Holmgren wrote: > > On torsdagen den 26 februari 2009, Gerber van der Graaf wrote: > > > 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? > > > > There are more examples, such as cyrus-sasl2, which contains two Kerberos > > GSSAPI modules, one using MIT Kerberos 5 and one using Heimdal. But because > > those libraries can't be installed simultaneously, there is a separate source > > package, cyrus-sasl2-heimdal, with a copy of the upstream tarball, which only > > builds the Heimdal module packages. Currently I don't think there is any > > other solution to this problem, and solving it "for real" would require > > rather serious changes to how packages are built, but it might still be > > meaningful to bring it up on -devel, which I've done now. > > > > The best reasonable solution is convincing upstream to build rather different > lib names and sonames for each case. That would imply that all people > depending on the mpi lib flavor should change their library names. Providing > the same kind of implementation in our distribution is a viable possibility, > but diverged by upstream: that should be done in the library package, while > the serial and mpi -dev packages still should retain the same names (and > conflict each other). This is what I will implement for the HDF5 case. > > -- > Francesco P. Lovergine > >
Attachment:
signature.asc
Description: This is a digitally signed message part