On Sun, 31 Aug 2014, Julien Cristau wrote: > On Sat, Aug 30, 2014 at 20:17:23 -0400, Yaroslav Halchenko wrote:
> > both ants and nifti2dicom (and probably others) recent FTBFS are due to > > recentish upload of hdf5 1.8.13+docs-8 which was previously only in > > experimental after its big RF in (1.8.13+docs-1) which stopped providing > > '/usr/lib/x86_64-linux-gnu/libhdf5.so' but provides separate builds for > > each flavor: > > /usr/lib/x86_64-linux-gnu/hdf5/mpich/libhdf5.so libhdf5-mpich-dev > > [amd64] > > /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so libhdf5-openmpi-dev > > [amd64] > > /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so libhdf5-dev [amd64] > > Gilles, I wondered, shouldn't there still be a > > /usr/lib/x86_64-linux-gnu/libhdf*.so* managed via alternatives, e.g. like > > blas/atlas do it? > alternatives are the worst possible way to handle a library. would you be kind to elaborate? alternatives is a pretty much a 'symlinks' manager to alternate between alternative implementations. That is why imho they work neatly for blas/atlas management. Here I see a similar use case if all those builds provide identical API/ABI. I would hate to build ants-mpich, ants-openmpi, ants-serial to provide alternative linkages. Or am I missing the point? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
