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

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