Alexander88207_protonmail.com retitled this revision from emulators/i386-wine-devel: Update to 5.22 to emulators/i386-wine-devel: Update to 5.22 & take maintainership.May 2 2021, 9:06 PM

Alexander88207_protonmail.com planned changes to this revision.May 2 2021, 10:25 PM

Thanks for offering to take maintainership and supporting our Wine ports @Alexander88207_protonmail.com

For this and future reviews, make sure to add existing MAINTAINER and/or relevent other people such that we get the appropriate eyes on the proposed changes. I'll add @gerald to this

@gerald mentioned a desire to find new maintainers for wine ports, so this is timely, thank you :)

This looks directional fine in terms of a version upgrade, thank you Alexander.

Note that Alex S, copied now, has argued for a while this port should go in favor of a much simpler solution. Alex, maybe you can share here?

(Also note I won't be able to fully test and commit, so another committer is necessary.)

In D29982#675506, @gerald wrote:

Note that Alex S, copied now, has argued for a while this port should go in favor of a much simpler solution. Alex, maybe you can share here?

Copied from email:

On Mon, Feb 15, 2021 at 7:38 PM Gerald Pfeifer <gerald@pfeifer.com> wrote:

On Thu, 11 Feb 2021, Alex S wrote:

LD_BIND_NOW=1 is definitely required, so something must be done there.
Do you have any objections to putting it into a wrapper script?

I'm flexible. Whatever works for our users (and isn't a maintenance
nightmare).

To be honest, wine-devel has been blatantly broken for 2 months due to
this issue and I've yet to see any complaints about that. Makes me
wonder what would happen if you just push a similarly broken update to
emulators/wine. Might be worth it just for that.

There is also the matter of outdated i386-wine packages, people using
those effectively can't and won't provide any feedback. Neither to us
nor to the upstream. We really need to find a way to get rid of
i386-wine(-devel) just for that reason alone.

To add insult to the injury, it's quite easy to download and use
i386 wine packages on amd64. Something like this:

pkg \
--option ABI=FreeBSD:12:i386 \
--option INSTALL_AS_USER=true \
--option RUN_SCRIPTS=false \
--rootdir ~/.i386-wine-pkg \
install wine

env \
PATH="$HOME/.i386-wine-pkg/usr/local/bin:$PATH" \
LD_32_LIBRARY_PATH="$HOME/.i386-wine-pkg/usr/local/lib/wine:\
/usr/local/lib32:$HOME/.i386-wine-pkg/usr/local/lib" \
LD_32_LIBRARY_PATH_RPATH=y \
LIBGL_DRIVERS_PATH="/usr/local/lib/dri:\
$HOME/.i386-wine-pkg/usr/local/lib/dri" \
env winecfg

(Scary? This is actually adopted from files/binbounce in i386-wine.)

I'm not sure how to sell this idea to actual users, though. This looks
like a downgrade on the surface (vs pkg install i386-wine). i386-wine
is also referenced in a lot of places — forum posts, YouTube videos
and whatnot. It's even in the Handbook now.

Also

On Tue, Feb 16, 2021 at 11:40 PM Gerald Pfeifer <gerald@pfeifer.com> wrote:

On Mon, 15 Feb 2021, Alex S wrote:

I'm not sure how to sell this idea to actual users, though. This looks
like a downgrade on the surface (vs pkg install i386-wine). i386-wine
is also referenced in a lot of places — forum posts, YouTube videos
and whatnot. It's even in the Handbook now.

Well, could i386-wine be re-implemented using that?

No, there is no way around that pkg incantation. The best we can do is
put those commands into wine(-devel) and maybe advertise them a bit in
pkg-message. That would look roughly like this (+wow64, +LD_BIND_NOW
workaround):

https://gist.github.com/shkhln/e39432d8b5f8d62da9b7d55aad641ddd

I'm not particularly fond of this hack, it's just that while we are
stuck without proper multilib it's not possible to meaningfully
improve upon it.

Disclaimer: I do not have a dog in this race, and would be okay dropping
i386-wine. I just do not feel in a position to drive/do this. Maybe once
regular wine-devel and wine have been addressed?

It's somewhat useful (?) to people willing to set up i386 Poudriere
builds, so maybe we should remove Makefile.amd64 once pre-built
packages degrade enough.

In D29982#675521, @iwtcex_gmail.com wrote:

…

That said, my previous attempt to advertise an out-of-package wrapper script for wine/wine-devel was a total failure from a discoverability/ergonomics point of view, so I intend to test this approach a bit with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255381. (Once somebody manages to commit it, that is.)

iwtcex_gmail.com resigned from this revision.May 4 2021, 7:24 AM

iwtcex_gmail.com added a subscriber: iwtcex_gmail.com.