Created attachment 209913 [details] wow64-option.patch Here is a small WoW64 patch per my comment at https://reviews.freebsd.org/D16830#498205. Note that this method requires wine-devel and i386-wine-devel to be built with compatible options and from the same source (version, patchset, etc). There is no sane way to enforce this in the Ports system, thus it's the end user responsibility.
Created attachment 209954 [details] wow64-option.patch v2
Created attachment 210022 [details] wow64-option.patch v3 + wine version vs wine64 version sanity check
Created attachment 210029 [details] wow64-option.patch v4 Forgot to disable WOW64 for normal (non-cross) i386 wine-devel build.
Created attachment 210031 [details] wow64-option.patch v5 Amazingly enough, some improvements are still possible there. I apologize for all the resulting notification email spam.
Ping. To my surprise I actually found that a little-known Linux distribution ;) going by the name openSUSE uses precisely this packaging method. No idea if their build process is similarly stupid.
I believe increasing PORTEPOCH is not appropriate here (or would require a detailed rationale). See https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-portepoch for some more details.
I also looked into this beyond this detail, but realisticly don't have the background nor infrastructure to properly test/debug/review this. Is there a way to move more of this into a separate port and keep the changes to wine-devel even smaller than you already have made them? I'll ask other FreeBSD committers for help, and am also willing to hand over maintainership of wine-devel altogether if that helps (or co-maintain with another committer).
(In reply to Gerald Pfeifer from comment #6) > I believe increasing PORTEPOCH is not appropriate here Ah, ok. That can be dropped. (In reply to Gerald Pfeifer from comment #7) > Is there a way to move more of this into a separate port Such as? > and keep the changes to wine-devel even smaller > than you already have made them? Well, the WOW64 option for wine-devel only suppresses the "wine-devel conflicts with installed package(s): i386-wine-devel" build message with no functional changes to the resulting package. This can be removed for a minuscule readability improvement.
Created attachment 210388 [details] wow64-option.patch v6 Without CONFLICTS_INSTALL changes. I was under impression that this variable might contribute something to the package metadata, but apparently it's only responsible for a warning message of very limited utility.
(In reply to Gerald Pfeifer from comment #7) > I'll ask other FreeBSD committers for help So, how is that going?
Closing due to a general lack of interest. Keeping this issue open prevents me from rebasing the lib32 patchset and I'd rather work on that. If somebody actually wants the patch, they can resubmit it separately.
(In reply to Alex S from comment #10) >> I'll ask other FreeBSD committers for help > So, how is that going? Nothing so far, but let's give it a bit. I really hope someone is going to step up. So far I have made this part of the "FreeBSD Quarterly Status Report", cf. https://lists.freebsd.org/pipermail/freebsd-announce/2020-January/001923.html And I sent a mail to all ports committers, cf. https://lists.freebsd.org/pipermail/svn-ports-all/2020-January/241434.html (since the ports-committers list is non-public). Plan B: would you be willing to assume maintainership of i386-wine-devel? The current maintainer is not active any longer and wondered about a successor. I noticed one or two bugs I'll fix myself this coming week, but if none of my fellow committers steps up and you want to take over, I'll commit an update of yours that includes making you maintainer. And then also go ahead with the changes to emulators/wine-devel that you suggested (just asking for your help on those pieces going forward since I cannot properly test).
(In reply to Gerald Pfeifer from comment #12) > And I sent a mail to all ports committers I see. Thank you for that. > The current maintainer is not active any longer > and wondered about a successor. That's a contentious question. I doubt anybody wants to be stuck with compiling and uploading i386-wine and i386-wine-devel packages. Doubly so considering Wine's biweekly release schedule. (cc jbeich here as the only person seemingly aware of the procedure) Maybe it's worth limiting official repo packages to i386-wine to keep this manageable? > if none of my fellow committers steps up and you want to take over, > I'll commit an update of yours that includes making you maintainer Thankfully, maintaining that port is completely impractical without a commit bit (too much communication overhead), so I'm safe from this opportunity.
FYI, the patch has been rewritten into a standalone helper script: https://gist.github.com/shkhln/3d0856683e1fc029d64cdaa6ba3e9393. This variant works with regular i386 wine packages.
(In reply to Alex S from comment #14) The problem is that i386-wine doesn't have a maintainer and your script needs the same wine version for both i386-wine and wine (what makes sense).
(In reply to Daniel Menelkir from comment #15) > The problem is that i386-wine doesn't have a maintainer The problem with i386-wine is that it exists. It's a local optimum we are stuck with. > and your script needs the same wine version for both i386-wine and wine You might want to read the script, it's not large and it _does not_ depend on i386-wine. It simply helps you manage a directory with i386 packages. I initially wanted to write a chroot helper, but apparently a couple of semi-obscure pkg options is all we need there.
(In reply to Alex S from comment #16) I read it, but I think I didn't catch it now. So I'm supposed to have wine installed on the system and a directory with my wine 32bit to fill the gaps?
(In reply to Daniel Menelkir from comment #17) > So I'm supposed to have wine installed on the system and a directory with my wine 32bit to fill the gaps? Yeah, pretty much that.