Bug#620241: elmerfem: unbuildable on ia64 (libatlas3gf-base build-conflict)

[Adam C Powell IV]

clone 620241 -1
reassign -1 src:mumps
retitle -1 Should Build-Conflict with libatlas3gf-base
block 620241 by -1
thanks

On Thu, 2011-03-31 at 19:03 +0200, Julien Cristau wrote:
> severity 620241 serious
> kthxbye
> 
> This bug may not belong to elmerfem but its severity is serious.  Which
> is why it was Cc:ed to the atlas and mumps maintainers.

When a fringe arch or two doesn't build a package properly, and it's
clearly not due to a problem in that package, it's usually not RC (in my
experience).  But I'll leave it that way if you prefer.

> On Thu, Mar 31, 2011 at 12:43:11 -0400, Adam C Powell IV wrote:
> 
> > On Thu, 2011-03-31 at 14:51 +0200, Julien Cristau wrote:
> > > Package: elmerfem
> > > Version: 5.5.0.svn.5100.dfsg-1
> > > Severity: serious
> > > Justification: fails to build from source
> > > 
> > > elmerfem/ia64 dependency installability problem:
> > >   elmerfem (= 5.5.0.svn.5100.dfsg-1) build-depends on one of:
> > >   - libmumps-scotch-dev (= 4.9.2.dfsg-6)
> > >   libatlas3gf-base (= 3.8.3-28) and source---elmerfem (= 5.5.0.svn.5100.dfsg-1) conflict
> > >   libmumps-scotch-dev (= 4.9.2.dfsg-6) depends on one of:
> > >   - libmumps-scotch-4.9.2 (= 4.9.2.dfsg-6)
> > >   libmumps-scotch-4.9.2 (= 4.9.2.dfsg-6) depends on one of:
> > >   - libatlas3gf-base (= 3.8.3-28)
> > 
> > This is not an elmerfem problem, as just 2/14 buildds got it wrong and
> > 11/14 got it right (Hurd is in Dep-Wait state).  The resolution is easy:
> > libmumps-scotch-4.9.2 depends on libblas3gf | libblas.so.3gf |
> > libatlas3gf-base, so install libblas3gf.
> > 
> On ia64 libmumps-scotch-4.9.2 depends on libatlas3gf-base.  No
> alternatives.
> 
> I assume that dependency on libatlas3gf-base is picked up through
> shlibs.  If that's incorrect then whatever package had wrong shlibs
> should be fixed.  Looking at
> https://buildd.debian.org/fetch.cgi?pkg=mumps&arch=ia64&ver=4.9.2.dfsg-6&stamp=1290984683&file=log&as=raw
> both blas and atlas were installed (atlas was probably picked up from
> libscalapack-mpi or some other dependency), and atlas doesn't list
> alternatives in its shlibs file.

The BLAS lib and the BLAS section of ATLAS are ABI-compatible, so BLAS
has shlibs indicating "libblas3gf | libblas.so.3gf | libatlas3gf-base".
Building with BLAS leaves resulting packages free to choose which to
link against.  Building with ATLAS, which sometimes happens by accident,
can lead packages to link with ATLAS only, which in turn can cause
problems with other packages, like Elmer.

So Elmer and a couple of other packages Build-Conflict with ATLAS in
order to force the BLAS build, allowing users to choose their BLAS
implementation at install time.

> > According to buildd.debian.org, every arch built blas 1.2-8 way back in
> > October.  And ftp.debian.org has hppa and ia64 packages for libblas3gf
> > 1.2-8, so hppa and ia64 have no excuse.
> > 
> I don't know what this is supposed to mean.

Just that it's odd that two buildds (ia64 and hppa) got it wrong when 11
others got it right and, the packages are available on ia64 and hppa, so
it's almost certainly not an Elmer bug.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20110331/22f668ea/attachment-0001.pgp>