Package Details: wine-ge-custom 1:GE.Proton8.26-6

Git Clone URL: https://aur.archlinux.org/wine-ge-custom.git (read-only, click to copy)
Package Base: wine-ge-custom
Description: A compatibility layer for running Windows programs - GloriousEggroll branch
Upstream URL: https://github.com/GloriousEggroll/wine-ge-custom
Licenses: LGPL-2.1-or-later
Conflicts: wine
Provides: wine
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 39
Popularity: 1.12
First Submitted: 2021-09-01 22:06 (UTC)
Last Updated: 2024-10-02 16:21 (UTC)

Required by (379)

Sources (7)

Pinned Comments

loathingkernel commented on 2022-03-02 14:12 (UTC)

@Strykar Nope, see https://aur.archlinux.org/packages/wine-ge-custom#comment-831304

You can grab compiled packages from https://github.com/loathingKernel/PKGBUILDs/releases/tag/packages

loathingkernel commented on 2021-10-15 10:01 (UTC) (edited on 2021-10-15 10:04 (UTC) by loathingkernel)

@thaewrapt, I see, you might be correct. The prebuilt package is not a good candidate for packaging for a couple of reasons. First of all, it is built using Lutris's runtime, and as such inherits the same issues as Proton, namely it is at its best when running inside that runtime. Also, although I might be wrong here, I haven't found any mention of Lutris being able to use a system-wide installation directory in the same way Steam can. For these reasons, I believe that packaging those binaries is pointless and they should be managed by Lutris itself.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 13 Next › Last »

niobium93 commented on 2023-07-14 10:26 (UTC)

Thank you :)

loathingkernel commented on 2023-07-14 10:21 (UTC) (edited on 2023-07-14 16:30 (UTC) by loathingkernel)

This is why we can't have nice things.

Ok, joking aside, I reverted everything back to normal and made wine-ge-custom-opt into its own thing. I am sorry for the inconvenience caused by these updates. In my defense, I had been sitting on these issues and solutions too long, unsure how to proceed because of lack of any feedback. Your feedback cleared a lot of things on how you are using this package and how it should be handled.

loathingkernel commented on 2023-07-14 08:02 (UTC)

Oh good lord, I forgot to pass arguments.....

saghm commented on 2023-07-14 04:18 (UTC)

Sorry for the repeated comments; from manual testing, I was able to get my games launching fine with Lutris and the "system" wine version from wine-ge-custom 8.10-5 by modifying the last line of /usr/bin/wine to the following:

exec /opt/wine-ge-custom/bin/wine "$@"

Quoting $@ was required to deal with the spaces in the path to my installed wine programs (due to "Program Files" having a space in the Windows path), and I added exec since it's idiomatic for shell scripts to use that to replace the current process rather than spawning an additional one (and keeping the old one around as a parent process).

saghm commented on 2023-07-14 04:01 (UTC)

From looking more closely at the issue @begin-theadventu has, I think the script in /usr/bin/wine just needs to forward additional arguments to the underlying wine binary as well, e.g. /opt/wine-ge-custom/bin/wine $@

saghm commented on 2023-07-14 03:54 (UTC)

Thanks for the quick response, the explanation of why my idea wouldn't work, and the quick turnaround on trying out a solution! I'm not sure there's any reasonable way to do this via an AUR package, but back before Lutris added a built-in way to use the experimental Proton build, I found a solution somewhere (unfortunately I can't remember exactly where, although maybe someone could dig it up with some google fu) that downloading it via Steam and then symlinking the directory into ~/.local/share/lutris/runners/wine would get it to show up in the list of wine versions in the Lutris menu. If people are having trouble getting Lutris to recognize wine-ge-custom-opt while things are being figured out, symlinking /opt/wine-ge-custom there might be a local workaround we can use in the meantime.

niobium93 commented on 2023-07-14 02:01 (UTC)

It'd be less hacky to just have a separate pkgbase for -opt.

begin-theadventu commented on 2023-07-14 01:01 (UTC) (edited on 2023-07-14 01:02 (UTC) by begin-theadventu)

Doesn't work with Lutris for me:

Usage: wine PROGRAM [ARGUMENTS...]   Run the specified program
       wine --help                   Display this help and exit
       wine --version                Output version information and exit
: ['wine', '--version'] command failed: Command '['wine', '--version']' returned non-zero exit status 1.
: Error reading wine version for wine

and Wine is not installed on your system. message.

loathingkernel commented on 2023-07-13 22:13 (UTC) (edited on 2023-07-13 22:37 (UTC) by loathingkernel)

So I implemented a solution to this situation. This is now a split package, the actual wine package is installed as wine-ge-custom-opt under /opt/wine-ge-custom. A compatibility package, that retains the name wine-ge-custom, installs the required files to emulate system-wide wine installation. The executables installed by wine-ge-custom under /usr/bin are scripts that setup the required environment variables to use the wine installation under /opt/wine-ge-custom.

Script example:

/usr/bin/wine

#!/usr/bin/sh
export PATH="/opt/wine-ge-custom/bin/:$PATH"
export LD_LIBRARY_PATH="/opt/wine-ge-custom/lib:/opt/wine-ge-custom/lib32:$LD_LIBRARY_PATH"
export WINEDLLPATH="/opt/wine-ge-custom/lib/wine:/opt/wine-ge-custom/lib32/wine:$WINEDLLPATH"
/opt/wine-ge-custom/bin/wine

I do not know if lutris will be happy with this approach but I think it is a lot cleaner than symlinks, if it has issues, I will use the symlink method instead.

I hope this will fit everyone's workflows. If something is wrong or incompatible please inform me.

as for suggestions, what do you think about about bringing back provides=wine but keeping conflicts=wine removed and keeping the installation in /opt? If I'm not mistaken,

This can't be done because packages that depend on wine would expect to find it in the usual location. wine-ge-custom being out of the proper PATH would make it unrecoverable to the packages depending on it despite providing it.

saghm commented on 2023-07-13 21:48 (UTC)

To add another data point, I also only use wine for gaming, so I was a bit confused about the error I got trying to update this package today, but I also was confused when initially installing the package months ago just to try out and having to remove wine-staging to be able to do so.

@loathingkernel, as for suggestions, what do you think about about bringing back provides=wine but keeping conflicts=wine removed and keeping the installation in /opt? If I'm not mistaken, this would allow people to install other packages that require wine but not stop people from installing alternate versions of wine (e.g. the ones in the main repos) as well. For those of who don't want or need another version of wine, we could make a second package that symlinks things into the old locations (e.g. /usr/bin) and has conflicts=wine to avoid issues, and this package could list it as an optional dependency (so that users installing this would be notified that they might want it as well). I guess this is sort of the same as the suggestion of having a separate wine-ge-custom-opt but inverting which package retains the existing name, but this way lets you continue to maintain this package in the current state without having to create and maintain the second package yourself (since from the sentiments expressed here, it seems like there's enough of a desire that one of us would probably take the initiative).

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 13 Next › Last »