Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 118521

Summary: blas-atlas update oscillation
Product: Gentoo Linux Reporter: Fritz Heinrichmeyer <fritz.heinrichmeyer>
Component: New packagesAssignee: Gentoo Science Related Packages <sci>
Severity: normal CC: Jochen.Trumpf, zeekec
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---

Description Fritz Heinrichmeyer 2006-01-10 05:26:45 UTC
in other words, i have an upgrade downgrade oszillation in portage concerning blas-atlas ...
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-01-10 05:32:12 UTC
Reopen with 'emerge -uDptv blas-atlas' output, we can't guess...
Comment 2 Fritz Heinrichmeyer 2006-01-10 06:12:28 UTC
you should not guess, you should know :-;

emerge -p scilab prints
[ebuild     UD] sci-libs/blas-atlas-3.6.0 [3.7.11] 
[ebuild  N    ] sci-libs/lapack-atlas-3.6.0-r1  USE="-debug -doc -ifc" 
[ebuild   R   ] sci-mathematics/scilab-3.1.1-r3  

i experimented by deleting sci-libs/lapack-atlas but the problem was there after world upgrade that brought


Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-01-10 06:23:49 UTC
Sigh, could you instead post the output you have been already asked to post in comment #1?  scilab does not have any version-specific dependencies wrt blas-atlas.
Comment 4 Fritz Heinrichmeyer 2006-01-10 06:33:50 UTC
the output of 
emerge -uDptv blas-atlas
here is of course empty as it is installed (look at comment #2).

"sci-libs/lapack-atlas" on the other side has


"hard coded", maybe this is a bug. Frankly, for my purposes a scilab without
blas-atlas as it was formerly would be the best for me.

Comment 5 Jakub Moc (RETIRED) gentoo-dev 2006-01-10 06:51:14 UTC
(In reply to comment #4)
> the output of 
> emerge -uDptv blas-atlas
> here is of course empty as it is installed (look at comment #2).

I of course meant the output of that command when that upgrade is relevant... Anyway, not really sure if there's any other "solution" beyond 'echo ">=sci-libs/blas-atlas-3.7.0" >> /etc/portage/package.mask'
Comment 6 Markus Dittrich (RETIRED) gentoo-dev 2006-01-10 08:52:24 UTC
I'll see that I commit a lapack-atlas-3.7.11.ebuild that works with the most
recent development snapshot of blas-atlas (3.7.11). This should resolve the
circular dependencies that you're experiencing. I need some time for testing
and will post back once it is in portage.

Comment 7 Fritz Heinrichmeyer 2006-01-10 13:46:46 UTC
(In reply to comment #5)
> Anyway, not really sure if there's any other "solution" beyond 'echo
> ">=sci-libs/blas-atlas-3.7.0" >> /etc/portage/package.mask'
as long 
depends on =sci-libs/blas-atlas-3.6.0 even this does not help. It should depend on =sci-libs/blas-atlas-3.6.0-r1.
Comment 8 Jochen Trumpf 2006-01-11 02:11:28 UTC
I disagree with comment #7: all lapack-atlas-3.6.0 ebuilds should depend on 
>=blas-atlas-3.6.0 && <blas-atlas-3.6.1
otherwise wrong versions might be pulled in when you run a (partial) testing (~arch) system, or testing versions might be required on stable systems (blas-atlas-3.6.0-r1 isn't stable on all arches yet).
It could be that lapack-atlas-3.6.0 would work fine with blas-atlas versions >3.6.0, so the second dependency might be unnecessary, but I don't know if this is the case. As far as I know, lapack-atlas uses some timing info from headers installed by blas-atlas.
Comment 9 Jakub Moc (RETIRED) gentoo-dev 2006-01-11 07:17:29 UTC
*** Bug 118664 has been marked as a duplicate of this bug. ***
Comment 10 Erik Zeek 2006-01-11 07:21:48 UTC
As I posted in Bug 118664:

lapack-atlas-3.6.0-r1 has a dependency on =sci-libs/blas-atlas-3.6.0, which
prevents it from using sci-libs/blas-atlas-3.6.0-r1 (and gives an annoying
upgrade downgrade cycle).  Changing the dependency to
=sci-libs/blas-atlas-3.6.0* fixes the problem.

    2006-01-11 10:11:48.000000000 -0500
+++ /home/gentoo/portage/sci-libs/lapack-atlas/lapack-atlas-3.6.0-r1.ebuild    
2006-01-11 10:11:55.000000000 -0500
@@ -21,7 +21,7 @@

-       =sci-libs/blas-atlas-3.6.0
+       =sci-libs/blas-atlas-3.6.0*
        ifc? ( dev-lang/ifc )"

Comment 11 Markus Dittrich (RETIRED) gentoo-dev 2006-01-11 08:30:13 UTC
Hi folks,

I have just committed lapack-atlas-3.7.11 that compiles against the 
latest blas-atlas development snapshot. Furthermore, lapack-atlas-3.6.0-r*
can not depend on any blas-atlas-3.6.0-r* revision. Hopefully, this should
resolve these circular dependency issues. For those who want to stay
with the unstable 3.6.0 branch, you will have to mask 3.7.11 in /etc/portage/package.mask.

Please reopen the bug if these issues still persist.

Comment 12 Markus Dittrich (RETIRED) gentoo-dev 2006-01-11 08:31:50 UTC
(In reply to comment #11)
> can not depend on any blas-atlas-3.6.0-r* revision. Hopefully, this should

This should have been "can NOW depend on any blas-atlas-3.6.0-r* revision.".