Re: Status of gfortran transition
On Thu, Oct 25, 2007 at 05:19:53PM -0400, Camm Maguire wrote:
> 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.
The provides make it a bit tricky yes. It should enough to
make libblas3 (or refblas3gf) Conflict: with all packages that
provide the blas interface built with g77.
You do not need conflict against *everything* linked against old
blas, since the conflict against the libraries in the "bottom" of
the dependency chain (refblas3, atlas) will make sure apps being
incompatible with the new blas will not be installed at the same.
Replaces is only need when you actually overwrite files from another
package.
> 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.
And if refblas3gf would conflict with atlas3-base, it would not have
been possible to link lapack against atlas3-base. Btw, I suggest
using a clean chroot for experimenting, it reduces risks of
getting compiled/linked against wrong versions,
Now there is still the open question of apt-get being unhappy when the
apt-get dist-upgrade path has lots of conflicts...
--
"rm -rf" only sounds scary if you don't have backups
Reply to: