Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating Non-AppImage Wine Binaries #59

Open
thw26 opened this issue Feb 17, 2024 · 0 comments
Open

Updating Non-AppImage Wine Binaries #59

thw26 opened this issue Feb 17, 2024 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@thw26
Copy link
Collaborator

thw26 commented Feb 17, 2024

In general, if a user is not using an AppImage, then the path to their binary is stable, i.e., /usr/bin/wine64. If the user is using Proton though, a couple of things could move the location of that binary or require updating the path. This would require manually editing the config file, which works. But it still requires user modification. I have gotten around this on my system using Proton by creating a symlink at /home/thwright/bin/wine64 and /home/thwright/bin/wineserver. I no longer need to modify the config, but I now have to maintain the symlink.

We could automate this by allowing the user to trigger installer.choose_install_method() and utils.get_wine_options() from the control panel to update the binary path.

The trouble with using the existing code is that it assumes the menu being created should display all options (i.e., binaries and appimages) because it assumes this is a first run. Conditional logic should make this easy to get around by checking the WINEBIN_CODE config and only supplying binaries of the same code. Checking the WINEBIN_CODE config is necessary as I have seen issues in trying to switch from an AppImage to a binary or from Proton to a system binary. Perhaps there is something else going on.

A more heavy hammer would be cleaning the wine bottle of everything pertaining to the current WINEBIN_CODE, moving the Logos install to a backup, then rerunning the creation of the wine bottle as during a first install, then moving the Logos install from backup back into position, sort of a combination of set new binary and backup and restore.

Should we add such an option? How could we do it well?

@thw26 thw26 added the enhancement New feature or request label Feb 17, 2024
@thw26 thw26 added this to the Release 1.0.0 milestone Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant