[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: simultaneous installation lib and lib-mpi



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.

-- 
Magnus Holmgren        holmgren@debian.org
Debian Developer 

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: