ufsparse -> suitesparse

[Axel Thimm]

On Fri, Aug 17, 2007 at 06:41:39PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 17 August 2007 at 18:35, Axel Thimm wrote:
> > On Fri, Aug 17, 2007 at 05:48:57PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > > > > freefem++ is one other thing depending on ufsparse, but it's not in CVS
> > > > > yet, awaiting arpack to pass review (Axel, are you alive there?).
> > > > 
> > > > Sure, I'm waiting for the lapack <-> atlas issue to be resolved.
> > > 
> > > Why haven't you filed a bug? You can't expect the problem to resolve by
> > > itself.
> > 
> > Well, I think I saw that this was your package and since we were
> > discussing this in the review I thought you were aware of it. I'm also
> > not sure whether this is really an issue, it was reported as such by a
> > reviewer (yum picking the smallest name for fulfilling a dependency or
> > something along the lines which makes atlas win over lapack).
> 
> To make things clear, because you seem a bit confused: arpack is your package
> and I am the reviewer.

well, I'm referring to reviewer before you picked it up, Michał
Bentkowski, who claimed that atlas broke arpack. But looking at the
bugzilla again he never wrote how and why, so maybe it's a Red
Herring?

> > At any rate the claim was that atlas(-devel?) provides equivalent
> > files like lapack but is still not working as a replacement. I haven't
> > checked whether this claim is true, this is something for lapack/atlas
> > experts to digest :)
> 
> It was. I only tested it as much as to confirm that
> yum install atlas ; rpm -e lapack blas
> doesn't prevent apps linked against these from running.

I digged out that bugzilla and found the following mysterious issue
with atlas-devel (not?) containing liblapack.so

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214967#c51
| The atlas vs lapack issue is quite mysterious:
| 
| # repoquery -q --whatprovides /usr/lib64/liblapack.so
| Importing additional filelist information
| atlas-devel-0:3.6.0-11.fc6.x86_64
| lapack-devel-0:3.1.1-1.fc6.x86_64
| # rpm -q atlas-devel
| atlas-devel-3.6.0-11.fc6
| # rpm -ql atlas-devel | grep liblapack.so$
| /usr/lib64/atlas/liblapack.so
| # rpm -q atlas-devel --provides
| atlas-devel = 3.6.0-11.fc6
| 
| So repoquery (and therefore also yum/mock) think atlas-devel contains
| %{_libdir}/liblapack.so while in reality it does not? I haven't looked at the
| atlas specfile, but the situation above should not be possible to happen.
| 
| Why is repoquery fooled that atlas-devel contains %{_libdir}/liblapack.so? It
| isn't a %file and not a virtual Provides: either.
| 
| (this comment probably belongs as a bug report against atlas or yum-metadata-parser)

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070817/6f6b1701/attachment.sig>