Package Details: wine-ge-custom 1:GE.Proton8.25-1

Git Clone URL: (read-only, click to copy)
Package Base: wine-ge-custom
Description: A compatibility layer for running Windows programs - GloriousEggroll branch
Upstream URL:
Licenses: LGPL
Conflicts: wine
Provides: wine
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 35
Popularity: 1.53
First Submitted: 2021-09-01 22:06 (UTC)
Last Updated: 2023-12-02 12:26 (UTC)

Pinned Comments

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

@Strykar Nope, see

You can grab compiled packages from

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 .. 11 Next › Last »

niobium93 commented on 2023-07-13 00:41 (UTC)

@loathingkernel Why would you do this. I don't want to install yet another wine version for no reason at all. It's bad enough proton is separate. dxvk, vkd3d-proton, wine-gecko, wine-mono, winetricks and many other packages all depend on just wine. This change also makes it difficult to launch wine-ge as the regular wine command will just run upstream wine now. I have tons of shell scripts that launch things in wine for me and I don't want to modify all of them. I urge you to reconsider.

begin-theadventu commented on 2023-07-12 21:39 (UTC) (edited on 2023-07-12 21:44 (UTC) by begin-theadventu)

I don't need the original wine, that's why I'm installing this package, but from now on this package will force me to install it, that's a pity..

I think it would be better if there was a separate package for installing wine-ge-custom along with the original wine.

loathingkernel commented on 2023-07-09 10:27 (UTC) (edited on 2023-07-09 11:46 (UTC) by loathingkernel)

@Piulinux They are there for parity with wine-staging PKGBUILD which this one is based on. It helps me with diffs to not touch things already there without a good reason.

The documentation is very clear on the matter. It is your job to ensure base-devel is installed if you want to use PKGBUILDs from the AUR.

Piulinux commented on 2023-07-09 10:03 (UTC) (edited on 2023-07-09 10:05 (UTC) by Piulinux)

Then why are flex, autoconf and bison in the makedepends? A missing pkgconf leads to abstruse errors like "Freetype is missing" when it's actually installed. So please add it.

I should only have to install base-devel if I want to build my own packages, not if I'm just using someone else's pkgbuild.

loathingkernel commented on 2023-07-09 09:41 (UTC)

@Piulinux For the millionth time, no they should not be. They are part of base-devel and that meta-package is assumed to be installed if you want to build packages from the AUR. It is literally the first point in the documentation

Piulinux commented on 2023-07-09 09:37 (UTC) (edited on 2023-07-09 09:38 (UTC) by Piulinux)

patch and pkgconf should be in the makedepends.

loathingkernel commented on 2023-06-09 10:52 (UTC)

@niobium93 No not really, but anything I can think of requiring 16bit are DOS games that can be run in dosbox. On the other hand it doesn't hurt, so I might as well enable it.

niobium93 commented on 2023-06-09 06:52 (UTC)

Is --disable-win16 really necessary? 16-bit games and applications still exist. It would be nice to be able to run them using the same wine I use for everything else.

vetu104 commented on 2023-05-25 17:53 (UTC)

Question towards anyone using this package, do you think it should be made to be install-able alongside regular wine or wine-staging from the repos but requiring some configuration overhead, or it is fine in the current state replacing those?

I would like to keep wine from arch repos in tact, and install this alongside.