Camm Maguire writes: > Matthias Klose <[EMAIL PROTECTED]> writes: > > > Changing the soname to a version which might be used by upstream for > > other purposes doesn't make sense. Please read our proposed transition > > plan (that resembles all other transitions which introduce changes not > > caused by the package itself): > > > > - do NOT change the soname > > - rename refblas3 to libblas3 > > - libblas3 conflicts/replaces refblas3. > > > > This way you cannot have packages (archive or third party) installed > > together. > > OK, there is a problem here. The existing packages that depend on the > blas interface have the following runtime dependency: > > atlas3-base | refblas3 | libblas.so.3 > > (defined in the shlibs.local) The latter is a virtual package. > lapack3, for example, acquires this dependency via linking in -lblas at > the last step. So installing libblas3 will replace refblas3, but make > anything linking against it or lapack3 segfault :-(. If the runtime > is made to conflict/replace, then we need to conflict/replace on > everything linked to it via some equivalent mechanism, I'd think, but > I'm sure I'm missing something here.
correct, that's the reason that the refblas3 NMU now calls: dh_makeshlibs -a -V "atlas3gf-base | refblas3gf | libblas.so.3gf" and the lapack3 NMU: dh_makeshlibs -a -V "atlas3gf-base | lapack3gf | liblapack.so.3gf" > This just bit me, as I was building lapack, which requires a blas lib > dev, and it was using an atlas version, which was build against g77. > These are runtime incompatible, and that is what it appears sonames > are for. so the new refblas3gf/librefblas3 has to conflict/replace atlas3-base and liblapack.so.3 as well. > I agree it might not be aesthetically pleasing to have an soname > differing from upstream, but I cannot see any other reason not to do > so. In fact, blas has no version number, so we make up an soname. It > would be ideal IMHO if the soname could be set to 3gf, but I'm not > getting too hopeful here (please tell me I'm overly pessimistic :-(). there's nothing wrong to set the soname to this string. In this case you may not need to conflict/replace the old binary library package, if the packages don't conflict otherwise. Not sure, how much this will help. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
