Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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

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.

Thanks for taking care of this Donnie!

best,
Markus

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.

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

works fine here as well!

Thanks,
Markus

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

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.

(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

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.

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?

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.

Guess I'll have to wait a month till eselect hits stable...

It's still not stable for some reason, but I'm closing this bug because it's
cluttering my list and it's fixed.