Re: Status of gfortran transition
Camm Maguire writes:
> Matthias Klose <firstname.lastname@example.org> 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