189942 2007-08-23 14:01 0000 eselect-{blas,cblas,lapack} can not reload a profile 2008-07-07 07:40:20 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED FIXED P2 normal --- 189722 1 markusle@gentoo.org dberkholz@gentoo.org sci@gentoo.org snf@extrospective.net markusle@gentoo.org 2007-08-23 14:01:27 0000 Hi folks, We've recently noticed the following issue with the eselect-{blas,cblas,lapack} modules. Presently, eselect seems unable to re-select an already exisiting profile which makes it impossible to update a user's system, e.g. after an upgrade which also changed the eselect profile for a particular module. As a concrete example, the sci-team is currently in the final stages of transitioning from "old-style" blas/cblas/lapack to "new-style" ebuilds. With this upgrade come enhanced eselect implementation files that provide additional links for pkg-config as well as header files. This means, that a user upgrading from old-style to new-style will need to re-select their current blas/cblas/lapack-implementation after the emerge to get these links or otherwise end up with a pretty crippled system. Currently, this does not seem to be possible despina eselect # eselect blas set atlas Implementation "atlas" already active for library directory "lib"! Failed to switch to implementation "atlas" for library directory "lib"! !!! Error: One or more actions have failed! and the only workaround seems to be to delete in /etc/env.d/blas/lib/config and then re-select. Could this be fixed or is there a way around this issue that we are not aware of? Thanks a bunch for your help/comments, Markus dberkholz@gentoo.org 2007-08-25 04:29:11 0000 It's my code, so I'll take the bug. It should indeed be possible. I think I specifically disallowed that possibility in the code because I didn't see the reason for it. markusle@gentoo.org 2007-08-25 12:24:02 0000 Thanks for taking care of this Donnie! best, Markus dberkholz@gentoo.org 2007-09-21 07:30:12 0000 Just comment lines 56-59 in /usr/share/eselect/libs/skel.bash and give it a try. If it works, I'll commit the change. bicatali@gentoo.org 2007-09-21 08:42:45 0000 > Just comment lines 56-59 in /usr/share/eselect/libs/skel.bash and give it a > try. If it works, I'll commit the change. works fine here. markusle@gentoo.org 2007-09-21 13:29:50 0000 works fine here as well! Thanks, Markus jakub@gentoo.org 2007-09-26 16:28:10 0000 *** Bug 193884 has been marked as a duplicate of this bug. *** dberkholz@gentoo.org 2007-10-15 09:38:54 0000 I just talked to ciaranm, and he said it would be fine if I released the skel.bash library independently of eselect. So I will put together an ebuild for it. markusle@gentoo.org 2007-10-16 12:32:06 0000 (In reply to comment #7) > I just talked to ciaranm, and he said it would be fine if I released the > skel.bash library independently of eselect. So I will put together an ebuild > for it. > Great and thanks for looking into this! Best, Markus dberkholz@gentoo.org 2007-10-20 04:32:48 0000 Heh, I didn't think this through clearly in advance. Releasing it as a separate module accomplishes nothing to speed things up, because we still need a full eselect release lacking it or they'll overwrite each other's files. dberkholz@gentoo.org 2007-10-28 08:10:07 0000 After further discussion with ciaranm, we've come to the conclusion that it might just be best to allow that collision, pushing this into a separate release without requiring a concomitant eselect release. Any thoughts? dberkholz@gentoo.org 2007-12-04 20:33:02 0000 Alright, the new eselect release (1.0.11) has this fix (finally). I think that if I add a minimal dep on that to eselect{blas,cblas,lapack}, then things will work out. dberkholz@gentoo.org 2007-12-04 20:48:22 0000 Guess I'll have to wait a month till eselect hits stable... dberkholz@gentoo.org 2008-07-07 07:40:20 0000 It's still not stable for some reason, but I'm closing this bug because it's cluttering my list and it's fixed.