Bug#685617: Allow co-installation of nvidia-kernel-dkms and nvidia-kernel-legacy-173xx-dkms

[Gaudenz Steinlin]

Hi Andreas

Any update on this? If there is anything you don't like about the patch
or anything that needs fixing. Please tell me. Otherwise it would be
really nice to finally integrate this.

Thanks,
Gaudenz

Gaudenz Steinlin <gaudenz at debian.org> writes:

> Hi Andreas
>
> Now that all the other issues with respect to co-installing the
> different nvidia generations are resolved I wanted to ask about your
> plans regarding the co-installation of the (dkms) kernel modules.
>
> Are you planning to apply my patches or implement an equivalent
> solution? Anything where you need help or would like to have updated
> patches?
>
> BTW, thanks for all the work you have done so far integrating my
> patches. Not really related to this bug, but what are your plans
> regarding the 319 and 304 branches? Will you soon upload 319 to unstable
> and are you planning to add legacy-304xx packages?
>
> I also built (unmodified) wheezy backports of the nvidia-settings-xxx
> and glx-alternatives packages for i386 today. If you want I can upload
> those to backports.
>  
> Thanks,
> Gaudenz
>
> Andreas Beckmann <debian at abeckmann.de> writes:
>
>> On 2012-08-23 00:18, Gaudenz Steinlin wrote:
>>> Andreas Beckmann <debian at abeckmann.de> writes:
>>>> Switching between current and legacy is done by reconfiguring the nvidia
>>>> alternative (/usr/lib/nvidia/nvidia) - can't that be used by the module
>>>> load script to select the "right" module?
>>
>>> In theory yes. But there are several problems:
>>> - plain alternatives are not possible because the files (the compiled
>>>   kernel modules) don't necesserily exist even if the package is
>>
>> No, I didn't want to install alternatives for the kernel module, just
>> get the status of the alternative (update-alternatives --query nvidia)
>> to do the correct selection.
>>
>>> (why not just select the best module if
>>>   we can).
>>
>> because the module must match the xorg driver and libGL
>>
>>> To be honest I did not look at the -source packages too closely. I'm not
>>> sure if they are still relevant.
>> They are not going away :-)
>>
>>> Dkms is IMHO the far superior and easier alternative.
>> But not suitable for all applications ...
>>
>>> But anyway the -source packages are already
>>> co-installable AFAICS.
>> The -source packages are co-installable, but the generated module
>> packages are not.
>>
>>> I don't know if there is a good way to modify the
>>> build system so that the module is renamed. As I think the -source
>>> packages are mostly relevant for manual builds I'm not even sure if it's
>>> a good idea to do such a modification there.
>> Having the -dkms and -source package building different modules (or
>> naming them differently) is a bad idea.
>>
>>> Agreed. Backports to wheezy would be cool though.
>>
>> Planned.
>>
>>
>> Andreas
>
> -- 
> Ever tried. Ever failed. No matter.
> Try again. Fail again. Fail better.
> ~ Samuel Beckett ~

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