Arch Linux

If your proton custom builds are actually providing alternatives to wine, should it provide wine instead?

While this sounds logical, it is not reasonable imho.

There are plenty of custom wine and custom proton versions out there. Some of them, like the packages i maintain are monolithic and therefore could not easily "provide" wine. They simply fail on being a system wide meaningful/usable instance of wine. That being said, the mentioned packages provide "proton" (also as a command) system wide - but i think this is a different story.
Long story short: i don't think winetricks depends on wine - it just manipulates wine prefixes. And as i already wrote, these could be created from different origins like the plenty of fixed wine and/or proton versions that playonlinux and lutris can provide, if they are configured not to use the system installed wine. And of course there is protonfixes, which doesn't even refer to vanilla wine but proton.

I agree with jaja, there are multiple wine derivates etc. and in my case I use https://github.com/varmd/wine-wayland and the winetricks installation still wanted to install wine.

Everyone who installs winetricks will know that they need some kind of wine software.

Do correct me if I'm wrong - the proton packages (at least the ones I've seen) are a group of (patched) components:
- wine
- dxvk
- vkd3d
- others

As such, the proton packages should provide() and conflict() each of their components... yet none of them do so.
Please fix the AUR packages - proton and other wine-like ones. See the guidelines https://wiki.archlinux.org/index.php/PKGBUILD - for the mentioned sections.

It has been a while but i come back to the issue at hand. It is still the same reasoning that drives me to ask for that change.

@Emil (xexaxo): The assumption you make is technically correct, but at least in case of packets proton-ge-custom-bin, proton-ge-custom, wine-tkg-roblox and wine-ge-custom you cannot divide them into their individual components.
They use the mentioned patched components, but they a) do not expose them to other tools to consume like the solo component package would do and b) do not interfere with the packets in question.
You may say it that way: the custom proton/wine packages are providing independent and _self-containing_ software packages that are not invoked like their "official" counterparts, nor are they providing a superset of the components included.

Over the last couple of years wine have moved to using built-in PE version of the misc components. I'm guessing proton has, or will be doing soon. So we can drop those from the discussion.

The request here is to change an official package so that it works AUR package. As such there is nothing to fix really here. A trivial fix on the AUR side is to "provide=(wine)" and call it a day.

It seems more like a hard dep than an optional dep:

$ ./winetricks
------------------------------------------------------
warning: wineserver not found!
------------------------------------------------------

I tend to agree that the AUR pkgs need to adapt.