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

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
Conflicts: wine
Provides: wine
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 36
Popularity: 0.67
First Submitted: 2021-09-01 22:06 (UTC)
Last Updated: 2024-03-05 18:38 (UTC)

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

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).

begin-theadventu commented on 2023-07-13 17:49 (UTC) (edited on 2023-07-13 18:07 (UTC) by begin-theadventu)

As I mentioned earlier, for me the best option would be to leave this package as it is, and create a separate one that would require standard Wine, something like wine-ge-custom-opt.

Personally, I don't need standard Wine AT ALL, so that's why I installed this package in the first place.

If I wanted to use wine-ge-custom along with standard Wine, I would probably just install and update it to my home folder with some simple script.

Anyway, in this case, I'll force move wine-ge-custom from opt and replace the original Wine files after each update and stop Wine updates.

airbreather commented on 2023-07-13 16:31 (UTC)

If you as consumers of the package want it reverted, I am happy to do it. I don't mind having a separate script for me. If you think we can find a workable solution that covers all bases, I am open to any suggestions.

For my part, this was quite disruptive for me, and so I was a bit peeved... but I also only have gaming use cases.

Having the full context, I now understand the reason why it was done, and I agree that this is probably the best approach going forward, even if it's going to disrupt people's workflows that they have built to-date.

Thank you for doing your part in making wine-ge-custom a better citizen of the Arch ecosystem.

Pook commented on 2023-07-13 15:52 (UTC)

The package now installs to /opt/wine-ge-custom Remember to update your scripts. I hope this helps if you have not had your coffee yet.

loathingkernel commented on 2023-07-13 11:08 (UTC)

@niobium93 @begin-theadventu You raise some good points, let me explain why this change was done. There are significant issues with wine-ge-custom and game launchers due to the FSHack, windows won't appear, cursor input remains in the other monitor etc. It is better for gaming but for anything close to desktop usage it starts to break down. This is the reason I made this change, I thought it would be better to have a system wine that is still usable under most circumstances.

If you as consumers of the package want it reverted, I am happy to do it. I don't mind having a separate script for me. If you think we can find a workable solution that covers all bases, I am open to any suggestions.

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.

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