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
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
"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.
(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'
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.
2006-01-11 10:11:48.000000000 -0500
2006-01-11 10:11:55.000000000 -0500
@@ -21,7 +21,7 @@
ifc? ( dev-lang/ifc )"
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.
(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.".