Bug#704914: glx-alternatives: The libGL diversion does not work

Christian Weeks cpw at weeksfamily.ca
Sun Apr 7 16:26:31 UTC 2013


On 07/04/13 12:17 PM, Andreas Beckmann wrote:
> Control: reassign -1 glx-diversions 0.2.90
> Control: tag -1 moreinfo
>
> On 2013-04-07 17:43, Christian Weeks wrote:
>> There is a severe problem with the libGL diversion strategy as exists at
>> present.
>>
>> The desktop is rendered inoperable after any change in the packaging, due to
>> the diversion in glx-diversions
>> being replaced by the actual lib from libgl1-mesa-glx. This is because gnome-
>> session-bin and other "current"
>> parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or
>> the virtual libgl1).
> I'm sorry, but what exactly is the problem you experienced?
libGL is brokenly referring to the libgl from mesa whereas it should be 
referring to the libGL from the nvidia packages. This breaks the gnome 
desktop. Gnome shell fails to start with an error, or any gnome 
application fails to launch, as the link is gone, replaced by the actual 
lib from that libgl-mesa-glx package. This affects almost all desktop 
applications that are linked against gnome.

This is with the current gnome 3.8 environment in experimental.
>
>> The only fix is to re-run "update-alternatives --configure glx", which re-
>> replaces the symlink diversion
>> however, if gnome is about to progress beyond experimental, it is likely this
>> is about to become a critical
>> pain point.
> So what is broken before this command and fixed afterwards?
Before: (This is reset after almost any packaging change on the system):
The link to libGL isn't a link to the diversions anymore. It is a link 
to somewhere else:
# ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 14 Apr  7 11:36 
/usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2.0
# ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
-rw-r--r-- 1 root root 414328 Dec 29 22:24 
/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
# dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0

Running the command:
# update-alternatives --config glx
There is only one alternative in link group glx (providing 
/usr/lib/glx): /usr/lib/nvidia
Nothing to configure.
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/nvidia because link group glx is broken

After:
# ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 Apr  7 12:23 
/usr/lib/x86_64-linux-gnu/libGL.so.1 -> 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu

If I do not run this command, after any package installation or update, 
Gnome is completely broken, because mesa isn't functional on this 
system, because it is using the NVIDIA libraries.

>
>> # dpkg --remove libgl1-mesa-glx:amd64
> and why would you want to do that?
Because it's the wrong thing for this system? It keeps replacing the 
nvidia GL with it's own? But I added it here because it shows how the 
libgl1 virtual dependency has crept from the base packages into the 
gnome packages.
>
>
> Unfortunately you reported this against the source package, so no
> scripts were run that could collect additional information.
> I've reassigned this bug to the glx-diversions package, please run
>    reportbug -N 704914
> on the *broken* system, that should collect some helpful information.
Acknowledged. That'll be run forthwith.
>
> Andreas
>



More information about the pkg-nvidia-devel mailing list