Homebrew-cask: wineskin-winery needs to be updated to run on 64-bit Mac OSX (Catalina+)

[deftdawg]

The current wineskin-winery cask points at a binary built in 2012.

While it starts fine, it is not actually capable of producing 64-bit Wine wrappers required for Windows apps to be able to run on OSX following the move to 64-bit only support with Catalina.

@Gcenx has patched the original wineskin-winery to handle both 32-bit and 64-bit wrappers, my suggestion would be replace this cask with his release of the software found at https://github.com/Gcenx/WineskinServer/releases

[miccal]

@deftdawg perhaps it might be best to create a new Cask for this fork of wineskin-winery, maybe called gcenx-wineskin-winery as per the token reference:

If the result conflicts with the name of an existing Cask, make yours unique by prepending the name of the vendor or developer, followed by a hyphen.

[ran-dall]

@deftdawg perhaps it might be best to create a new Cask for this fork of wineskin-winery, maybe called gcenx-wineskin-winery as per the token reference:

If the result conflicts with the name of an existing Cask, make yours unique by prepending the name of the vendor or developer, followed by a hyphen.

@miccal @deftdawg This is correct. Also, wineskin-winery has been downloaded just over 300 times in the last 30 days; which overall for HBC isn't a lot; however, it still wouldn't be proper to replace it with an entirely different project. You can look at the case of chromium as an example; there are several casks of chromium (at least 2 or 3 to my recollection), all with specific names.

[Gcenx]

I have a brew tap for installing my project along with PortingKit and wine-crossover.

brew tap gcenx/wine
With a cask name of unofficial-wineskin

For reference Wineskin Winery from doh123 is no longer updated nor maintained, the last available wine versions are Wine-2.22 and Wine-Staging-2.21.

It also has numerous bugs with GPU detection starting with High Sierra.

[tjnycum]

Also, wineskin-winery has been downloaded just over 300 times in the last 30 days; which overall for HBC isn't a lot; however, it still wouldn't be proper to replace it with an entirely different project. You can look at the case of chromium as an example; there are several casks of chromium (at least 2 or 3 to my recollection), all with specific names.

But it _isn't_ an entirely different project; it's a tail fork. In the case of chromium, the various forks have to have different names in order to co-exist in HBC, right? That's not an issue here. The original wineskin is dead enough that you've deleted the formula, so there's no name conflict.

Given that, is there really an issue with continuing the formula under the same name, tracking a fork, besides identifying the best successor?

[vitorgalvao]

The original wineskin is dead enough that you've deleted the formula, so there's no name conflict.

“Cask”, not “formula”.

And that could still cause confusion. A name conflict isn’t the only issue; we should reduce ambiguity between what’s being installed. The only way a fork gets the token name of the cask it’s forking is if the original developers point to that fork as a successor in some way. An official endorsement, if you will.

Alternatively, the fork could be so overwhelmingly popular that it surpasses the original and is now the de facto project when people think of the name.

Given that, is there really an issue with continuing the formula under the same name, tracking a fork, besides identifying the best successor?

Yes, “identifying the best successor” is indeed the missing piece, but we’re not going to give ourselves the authority to point to the successor, it has to happen in one of the two ways mentioned above.

[ran-dall]

@vitorgalvao You beat me to it. 😁

@tjnycum However one thing I also like to add. Even if we did make an exception with the name, the fork wouldn't pass standard Notability Requirements. So I think @Gcenx's solution is your best bet.

[Gcenx]

@ran-dall I’m assuming your referring to the SIP section?