One that particular version has been removed the shortcut stops working
The shortcut doesn't respect selecting the wine flavour with eselect wine
I suppose you mean the same problem as I see -- .desktop files containing:
Exec=env WINEPREFIX="..." /usr/lib/wine-any-3.21/bin/wine
What do you expect to happen if you have two slots of wine-any installed? If the shortcuts from both pointed to /usr/bin/wine, both shortcuts would open the eselect wine version.
I don't know of a good solution that preserves the multislot use case.
Shouldn't /usr/bin/wine be controllable by select
You don't want to break everyone's shortcuts every 2 weeks when there's a new release
Exactly. The current behavior means that whenever wine is upgraded, all .desktop files are broken and need to be fixed manually.
It should be pretty easy to fix. I'll try to get to it soon. PRs always welcome.
@Mike or Michał,
Can one of you point me to the location of one of these shortcut files pointing to a specific wine version?
I'm looking in /usr/share/applications, and they seem to be general:
Exec=wine-d3d9 start /unix %f
Exec=wine start /unix %f
I'm sorry, I meant ~/.local/share/applications
Thanks, I reproduced it.
This is due to the implementation of the desktop file writer.
The only fix I know of would be to hardcode to "/usr/bin/wine" in that file. Not sure if that's safe to do.