Bugzilla Bug 118521

in other words, i have an upgrade downgrade oszillation in portage concerning
blas-atlas ...

Reopen with 'emerge -uDptv blas-atlas' output, we can't guess...

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 

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.

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.

(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'

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

(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.

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.

*** Bug 118664 has been marked as a duplicate of this bug. ***

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

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

(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