Bug#688749: Add alternatives for nvidia-settings and nvidia-settings-legacy-173xx

[Gaudenz Steinlin]

Andreas Beckmann <debian at abeckmann.de> writes:

> On 2012-09-25 13:16, Gaudenz Steinlin wrote:
>> Please add alternatives for the current and legacy nvidia-settings
>> packages to make them co-installable. This is yet another necessary fix
>> to have both drivers available on Debian Live systems.
>
> Is this something you want to see in wheezy? In that case please ask for
> a freeze exception. Otherwise this will be delayed after the release.

Having it in wheezy would be nice, but as the dkms co-installation
changes are post-wheezy as well I don't think it matters much. I'm fine
with having it in backports.

I need this for a Debian Live based project and the main purpose of the
bug reports is that we want to play nice with upstream and that we don't
want to carry these patches indefinitely.

>
>> + ALTERNATIVE_FILES=...
> you need some quotes there ...

I'm by no means a make expert, but I don't think so. At least when I
added quotes then the quotes ended up being part of the variable.

>
> 304xx will be a new legacy branch, probably we need to fork
> nvidia-settings-legacy-304xx, so we should keep this in mind and could
> use proper names right from the beginning ...
>
> The #LEGACY_OR_CURRENT# approach does not work for 96xx with has to use
> nvidia-settings-legacy-173xx
> #SETTINGS_SUFFIX# might be more generic

I don't completely understand your concerns here. But maybe I also don't
know enough about your workflow when a new version is released and the
current one becomes legacy-XXXXX. I agree that LEGACY_OR_CURRENT is not
the best name and could be renamed to SETTINGS_SUFFIX. But having the
suffix legacy-304xx for the 304xx version even if no newer version is
released does not sound right.

Isn't the 96xx only a transitional package to install nouveau? As this
is wheezy+ only I don't think 96xx is relevant anymore.

>
> If we rename nvidia-settings.png to nvidia-settings$SUFFIX.png and use
> this in the .desktop file, we can avoid an alternative.

Yes true the alternative on the png file can be avoided. 

>
> With your patch, the menu entry will only be available if
> nvidia-alternative is installed, while the binaries/manpage can be
> reached with their specific names (not the generic nvidia-settings name).
>
> What happens if we use nvidia-settings$SUFFIX.desktop (and no
> alternative for this one, too)?

The problem with this approach is that then you have both versions in
the menu if both are installed. But users probably only want to see the
one that actually works. On the other hand I don't know a good solution
for the case where nvidia-alternative(-legacy-173xx) is not installed.
How is this case handled for the other alternatives?

> PPS: a single bug which affects the other packages would have been
> sufficient for the beginning (or even assigned to the 4 packages:
> Package: pkg1,pkg2,pkg3,pkg4) as it reduces the number of copies of the
> patches floating around ... lets keep discussion and updates here

The problem with these two solutions is that the bug get's closed as
soon as it's fixed in one of the packages. But that's not the case for
this bug. It needs an upload of all 4 packages. But I agree that
discussion is best kept either just to one report or then CCed to all of
them. Keeping the discussion on this report is fine for me.

Gaudenz

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