Bug#702782: broken glx alternative

[Gaudenz Steinlin]

Andreas Beckmann <anbe at debian.org> writes:

> Hi Gaudenz,
>
> On 2013-03-12 15:07, Gaudenz Steinlin wrote:
>> You could still manage the alternatives from the nvidia package, but
>> instead of doing it with the nvidia alternative just directly add it as
>> another option to the glx alternative.
>
> one of the problems was the priority space ... which package gets which
> priority?
> * mesa
> * fglrx
> * fglrx-legacy (currently not co-installable with fglrx since it came
> last-minute and did not make it into testing)
> * nvidia 96xx legacy
> * nvidia 173xx legacy
> * nvidia 304xx legacy
> * nvidia current
> (it's even possible to turn every nvidia major version branch into a
> co-installable (currently excluding -dkms) set of legacy-ABCxx packages)
>

I'd say that mesa should get the highest priority and the more recent
versions of the proprietary drivers should get a higher priority than
the older ones. The priority between fglrx and nvidia does not really
matter because I don't know any system where you need both of them at
the same time. I also think that the priorities are not really important
as if you have more than one alternative installed you probably want to
select the right one based on the hardware and based on static priority
numbers.

>
>>> please try
>>>   dpkg-reconfigure glx-alternative-nvidia
>>> after manually changing the nvidia alternative
>> 
>> Yes that works. But with the package from experimental it also updates
>> the initramfs. Which takes some time if done during boot and is quite
>> useless unless your next boot is on the same hardware.
>> 
>> To just fix the alternative "update-alternatives --set glx
>> /usr/lib/nvidia" is enough. But it's IMHO still a bug that you have to
>> fiddle with the glx alternative just to fix the nvidia one.
>
> Well, I haven't done detailed testing of the switching in a life-system
> relevant setup involving manual configuration (or 'automatic' manual
> setting of the nvidia and glx alternatives). As long as only packages
> are installed/removed, the alternatives are correct.
>
> Anyway, it's too late to change anything significant here for wheezy, so
> the only thing could be to document this properly. I've added the
> dpkg-reconfigure command to README.alternatives that will be in 304.84
> ... but that is probably not the place where people will look.

I fully agree that this is post wheezy material and a documentation note
is OK for wheezy. I guess you could add a not the NEWS.Debian so that
it's shown with apt-listchanges.

For the live distribution I currently help developing we mostly care
that we don't have to carry a diff to Debian forever. Doing a backport
is OK for us.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~