How to report bugs concerning the diversions and alternatives ============================================================= You are probably reading this section because the installation of the glx-diversions package failed. You seem to have a configuration that we didn't encounter so far and therefore the migration path did not work. Please report a bug *before* you try to fix your system manually, so that some information about your setup can be collected. This will help us to fix this problem. You need to have the 'reportbug' package installed, then run reportbug glx-diversions This will collect information that will help us debug the problem. The 'reportbug' command will give further instructions. You may want to attach /var/log/apt/term.log, too, which contains a transcript of the recent package installation/update sessions. Older history is preserved in term.log.1.* etc. Root access is required to read or copy these logfiles. -- Andreas Beckmann Wed, 29 Jun 2011 13:15:14 +0200 Short summary about selecting a glx implementation ================================================== To switch between the GLX implementation from MESA and NVIDIA, run update-glx --config glx Detailed description of the diversions/alternatives for libGL.so.1 etc. ======================================================================= The GPU vendors NVIDIA and AMD provide proprietary drivers including GLX acceleration for their hardware. Therefore they need to replace the free implementation of libGL.so.* (from MESA) and the X.Org module libglx.so with a vendor implementation. NVIDIA furthermore maintains several legacy driver versions that support older hardware. Simply packaging all of them and having each packaging divert the files that are going to be replaced (as it was done in the past) causes several problems: - All the packages conflict with each other, so only one driver can be installed at a time and it can only be disabled (i.e. switching back to MESA) by uninstalling the driver again. - While a single driver should be sufficient for e.g. a normal desktop system, it is insufficient for e.g. a live CD (which would have to detect the GPU, select the appropriate driver and libraries and configure X.Org accordingly at boot). - The rather complicated code maintaining the diversions is duplicated several times. Therefore we changed this in the following way: - Only one package (glx-diversions) handles the diversions, any package requiring the diversions of libGL.so*, libglx.so needs to declare a dependency on this package. - Vendor implementations are installed into a private library directory instead of the locations of the diverted files. This allows parallel installation of different drivers without becoming active immediately. - To activate an implementation (and to allow easy switching between them) an alternative "glx" is being registered with slave alternatives for all the libraries, modules and other files of that implementation. This is handled by the glx-alternative-{mesa,nvidia} packages. - As the implementations are split into several packages and optional packages may be installed/removed later on, triggers are being used to automatically update the alternatives whenever files of that vendor implementation are added or removed. To switch between the GLX implementation from MESA and NVIDIA, use the command update-glx --config glx This will also trigger an update of the initrd with a possibly changed kernel module blacklist. For NVIDIA an additional alternative exists that allows one to switch between the current driver and legacy versions. For selection use the command update-glx --config nvidia The actual list of choices of course depends on the packages currently installed on the system. libGL.so ======== The libGL.so link is managed by a dpkg trigger as an alternative, too. But there are no alternative solutions available besides the diverted link from the libgl1-mesa-dev package (if this package is installed), so this cannot be reconfigured. The intention behind this is to always link an application at compile time to the MESA implementation of libGL.so.1 in order to produce portable binaries, but to use the accelerated libGL.so.1 when the application is being executed. If an application crashes because it does dlopen(libGL.so) at runtime, this is a bug in the application, dlopen(libGL.so.1) needs to be used instead. -- Andreas Beckmann Wed, 01 Aug 2012 21:40:12 +0200