[Debian-med-packaging] Bug#658307: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev

[Steve M. Robbins]

Hi,

I'd like to contribute towards a solution for this.  I'm forwarding to
debian-devel to get some others' ideas.


On Wed, Feb 01, 2012 at 09:57:39AM +0100, Sylvestre Ledru wrote:
> Le mardi 31 janvier 2012 à 21:56 -0600, Steve M. Robbins a écrit :

> > Naively, I don't understand why netcdf can't offer multiple variants,
> > just as hdf5 does.  Or, at least, one package libnetcdf-mpi-dev that
> > links with the "default" MPI implementation.
> I am not involved in the netcdf. You should report a bug on this
> package.

I'm prepared to do so, but I'd first like to get agreement that
netcdf is where the problem lies.  Netcdf maintainers, please
chime in!


On Wed, Feb 01, 2012 at 05:44:49PM +0100, Francesco P. Lovergine wrote:
> On Tue, Jan 31, 2012 at 04:41:06PM +0100, Sylvestre Ledru wrote:
> > Even if I am not happy about this change, it is expected.
> > libnetcdf-dev depends on libnetcdf7 which depends on libhdf5-7.
> > libhdf5-openmpi-7 conflicts with libhdf5-7.
> > 
> > Before I had the silly idea to become a hdf5 maintainer, I reported this
> > bug myself #591346.
> > For now, I haven't find the right solution to tackle this issue ... 
> > Suggestions are welcome.
> > 
> 
> The solution is having upstream adopting a sane naming scheme for mpi-enabled
> flavor libraries instead of using always the same names for all.

Francesco, please clarify: are you speaking of the hdf5 upstream or
the netcdf upstream?  (Both?)  

What problem are you trying to solve with that: co-installable -dev
packages or just coinstallable lib packages?


> Unfortunately they were still not available for that at the time of
> my last poking.  Diverging from upstream is not a good idea, so we
> still have to live in a non perfect world...

I think we can no longer live in the status quo (see all the blockers
of #631019), so something has to give.  Even if it is painful, perhaps
Debian could pioneer something and pass patches back to upstream?

Thoughts?

-Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20120201/94d9a059/attachment.pgp>