Bug 118521 – blas-atlas update oscillation

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[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) 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

sci-libs/blas-atlas-3.7.11 

[Comment 3 Jakub Moc (RETIRED) 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

=sci-libs/blas-atlas-3.6.0

"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) 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) 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.

Thanks,
Markus

[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 
lapack-atlas/lapack-atlas-3.6.0-r1
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) 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.


---
/home/gentoo/portage/sci-libs/lapack-atlas/lapack-atlas-3.6.0-r1.ebuild.orig   
    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 @@

 DEPEND="virtual/libc
        >=sys-devel/libtool-1.5
-       =sci-libs/blas-atlas-3.6.0
+       =sci-libs/blas-atlas-3.6.0*
        sci-libs/lapack-config
        ifc? ( dev-lang/ifc )"

[Comment 11 Markus Dittrich (RETIRED) 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.

Thanks,
Markus

[Comment 12 Markus Dittrich (RETIRED) 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.".

Sorry,
Markus