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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
