|Summary:||blas-atlas update oscillation|
|Product:||Gentoo Linux||Reporter:||Fritz Heinrichmeyer <fritz.heinrichmeyer>|
|Component:||New packages||Assignee:||Gentoo Science Related Packages <sci>|
|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) 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