Alastair McKinstry a écrit , Le 12/06/2014 07:54: > On 12/06/2014 00:43, Gilles Filippini wrote: >> Alastair McKinstry a écrit , Le 11/06/2014 12:15: >>> I've pushed some work on this to a dev-alternatives branch on alioth. > >> Thanks a lot for this work. >> How did you produce the detailed map files? What is the recipe to use >> when updating to a new upstream release? > > The symbols change information came via dpkg-gensymbols. In practice the > map file needs > to be done by hand as you need to check what symbols changed and how (to > cope with modifications > rather than just additions). > As this is the first versioning map file, the symbol names have no > significance other than to > document the version in which they were added, but it is important to > enumerate each symbol > and eliminate as many local symbols as possible. This actually is a huge task. Some helper scripts might be desirable here. BTW, shouldn't these map files be split into parts so that each one matches one target library: libhdf5, libhdf5_fortran, ...? > For linking multiple hdf libs, the symbol names need to be different > between variants, hence > HDF5_SERIAL_1.8.11 vs HDF_MPI_1.8.11 > As far as I can tell, the MPI variants are equivalent. > > >>> This is still a work in progress but I've got co-installable serial & >>> parallel netcdf building from this; > >> As I said before I really don't see any use for setting an alternative >> against all flavors of the library. What could be the use case for that? > My aim is that any existing setup will continue to work; ie. if you have > mpich2 and hdf5-mipch2 dev libs > installed on a wheezy system with local binaries built, then this should > still work when upgraded to jessie. > Also, any upgrades should minimize necessary changes. If you build a > binary locally with openmpi + hdf5 openmpi, > then change to mpich, it should continue to work , as the binary will > have been built against the hdf5_mpi interface > rather than an mpi-implementation specific version. I'm relly not sure about this last part. Won't the resulting executables have a dependancy on the MPI flavor they were linked with in the first place? > > Do you think we should not do this, or do this differently? My take on this is that - because of the soname bump - downstream users will *have to* rebuild their software depending on libhdf5, anyway. Then I'd prefer a big fat warning telling them to add proper -I and -L flags than carrying misleading and mutually exclusive default configurations via alternatives. The whole purpose of this work is to get rid of this kind of conflicting settings after all. > >>> For the incongruity, I'd already implemented the rename when you replied >>> and found it easier >>> to simply add a symlink for compatability. I can back it out if peeople >>> disagree. > >> I still disagree about changing an upstream library name just for a >> cosmetic matter. > Ok, i'll back it out. Thanks! I'm going to have a relly busy w-e. I'll start to merge your changes into my experimental branch by monday.
Attachment:
signature.asc
Description: OpenPGP digital signature