Re: simultaneous installation lib and lib-mpi
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
Reply to: