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
Hi Mike, 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. Sarnex
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.
Okay, thanks. 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: wine-d3d9.desktop: Exec=wine-d3d9 start /unix %f wine.desktop: Exec=wine start /unix %f Thanks, Sarnex
~/.local/applications
I'm sorry, I meant ~/.local/share/applications
Thanks, I reproduced it. This is due to the implementation of the desktop file writer. https://github.com/wine-mirror/wine/blob/master/programs/winemenubuilder/winemenubuilder.c#L1467 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. Sarnex
Ping.
It doesn't seem that cut and dry that it's a problem in winemenubuilder. The file and portion linked doesn't insert wine on a path, or the calling binary, but just inserts the literal 'wine', not a variable, and those lines in write_desktop_entry haven't been touched since at latest 2010. This really needs to be higher priority as it breaks the expectation every time you invoke a wine-installed menu shortcut in that unless you stay on one version forever, it's *unexpectedly* calling a totally different version than what you have set as default, and Gentoo no longer offers unslotted wine as a workaround. Is that getting expanded somewhere akin to "realpath `which wine`"?
I'm a moron https://github.com/wine-staging/wine-staging/blob/6bfaa3b0a5c195d4bec9e0b60804f9a36106b925/patches/winemenubuilder-Desktop_Icon_Path/0001-winemenubuilder-Create-desktop-shortcuts-with-absolu.patch Fixing it now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=78a31d50c4598a4ad05ed2481770a1ccc996f320 commit 78a31d50c4598a4ad05ed2481770a1ccc996f320 Author: Nick Sarnie <sarnex@gentoo.org> AuthorDate: 2020-04-02 02:18:57 +0000 Commit: Nick Sarnie <sarnex@gentoo.org> CommitDate: 2020-04-02 02:18:57 +0000 app-emulation/wine-staging: Fix shortcut bug Closes: https://bugs.gentoo.org/652176 Package-Manager: Portage-2.3.96, Repoman-2.3.22 Signed-off-by: Nick Sarnie <sarnex@gentoo.org> .../wine-staging/wine-staging-5.5-r1.ebuild | 621 +++++++++++++++++++++ .../wine-staging/wine-staging-9999.ebuild | 2 +- 2 files changed, 622 insertions(+), 1 deletion(-)
