Re: Status of gfortran transition

[Matthias Klose <doko@cs.tu-berlin.de>]

Camm Maguire writes:
> Matthias Klose <doko@cs.tu-berlin.de> 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