Hi!

On Wed, 22 Aug 2018 20:33:00 +0200 Davyd McColl wrote:
> The other day I installed Celestia for the entertainment of my son, who is
> delighted with anything stellar / planetary. Celestia wouldn't start up,
> and, long-story-short, I tracked down the issue to the symlinks:
>
> /usr/lib64/libGL.so
> /usr/lib64/libGL.so.1
>
> which ultimately point to
>
> /usr/lib64/libGL.so.1.2.0,
>
> provided by media-libs/mesa. Naturally, I assumed I'd made a mistake with
> `eselect` at some point, so I checked with `eselect opengl list` and found
> that, as expected, my selected opengl implementation was nvidia. Just in
> case, I switched over to xorg-x11 (mesa) and back again, but this didn't
> fix the problem.
>
> Manually redirecting these to /usr/lib64/opengl/nvidia/lib/libGL.so
> (provided by x11-drivers/nvidia-drivers) works, however, of course, portage
> doesn't know anything about this, so the update I received today for
> media-libs/mesa reverted these symlinks back to pointing at mesa libs.
>
> So the questions I have are these:
> 1) Am I reasonable in expecting `eselect opengl` to maintain these
> symlinks? I feel like it's a reasonable expectation, but perhaps there's
> just yet another thing I have to learn / understand.

No, eselect opengl works differently. It uses /etc/env.d to alter
LDPATH and OPENGL_PROFILE environment variables. It also changes
xorg.conf.

So you may need to restart your X server and source /etc/profile in
active shells for changes to take effect.

> 2) Should I be logging a bug (against eselect, or perhaps celestia, since
> this is the only app which seems to have suffered this fate -- games like
> Torchlight 2 and utils like glxgears work just fine; glxinfo reports NVIDIA
> extensions), or is there just something I've fundamentally missed or messed
> up here?

If glxinfo reports correct data and glxgears works fine, then this
may be a bug and please report it. You may CC both celestia and
opengl since right now it is not obvious which is the culprit.

Best regards,
Andrew Savchenko