generalizing the diversions/alternatives and allowing parallel installation of current and legacy drivers ...

[Andreas Beckmann]

Hi Russ,

I'm looking for a good package name to be added to the drivers package.
The package will have triggers and provide one alternative that allows
to switch between different versions (i.e. current and legacy) of the
nvidia drivers.
Therefore all the things currently in /usr/lib/nvidia will be moved to a
private subdir of that location (/usr/lib/nvidia/{current,legacy-ABCxx})
and an alternative with a lot of slaves will be used to put appropriate
links into /usr/lib/nvidia (and elsewhere, like
/usr/bin/nvidia-bug-report.sh). This is neccessary to avoid mixing
different versions. Having a separate alternative for each single file
will call for trouble as it allows mixed configurations.

So this new package will be a dependency of nvidia-glx,
libgl1-nvidia-glx, nvidia-vdpau-driver, the -ia32 variants, ...
eventually in the future libcuda1 will be added in case a new legacy
package is introduced at some point.

Therefore the new package name should not be too specific to glx or the
xorg things ... and allow for a #LEGACY# placeholder.
I just couldn't come up with a good name ... nvidia#LEGACY#-select?
nvidia#LEGACY#-enable?

Let's ignore the problem with the name conflicting kernel module for now.

Then we will need one more package that does set up one alternative with
some slaves (that is currently done by 3 separate alternatives in
nvidia-glx and libgl1-nvidia-glx{,-ia32}) to actually enable nvidia as a
glx provider for the system. Hopefully we can coordinate this with the
fglrx maintainers, so that at some point a user could have a lot of
libraries installed and run
  update-alternatives --configure glx
and gets the three choices "mesa, nvidia or fglrx?"
while
  update-alternatives --configure nvidia
allows to switch between "current, legacy-299xx, legacy-173xx, legacy-96xx".
I just couldn't come up with a good name ... glx-select-nvidia?
glx-enable-nvidia? glx-alternative-nvidia?

Thinking multiarch, these alternatives providing packages will have to
be Multi-Arch: foreign and need to be aware of the (luckily only two)
triplets where the libraries could reside below /usr/lib, same goes for
diverting packages.

Anyway, the libgl*-nvidia-alternatives* packages should be moved to a
separate source package in contrib, what about glx-alternatives?
There we could have one or more glx-diversions-foobar packages (which
take over operation from libgl*-nvidia-alternatives*) and the
glx-select-nvidia (or however it will be called) along with a
glx-select-fglrx package should be provided there as well. The this will
be the central point that knows about the diversions and the
alternatives needed by all the different implementations ...

Andreas