Created attachment 209913 [details]
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]
Created attachment 210022 [details]
+ wine version vs wine64 version sanity check
Created attachment 210029 [details]
Forgot to disable WOW64 for normal (non-cross) i386 wine-devel build.
Created attachment 210031 [details]
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).
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
> 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]
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.