Bug 242625 - Somewhat limited WoW64 support for emulators/wine-devel, emulators/i386-wine-devel
Summary: Somewhat limited WoW64 support for emulators/wine-devel, emulators/i386-wine-...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-13 14:50 UTC by Alex S
Modified: 2020-01-04 00:10 UTC (History)
6 users (show)

See Also:


Attachments
wow64-option.patch (3.82 KB, patch)
2019-12-13 14:50 UTC, Alex S
no flags Details | Diff
wow64-option.patch v2 (4.50 KB, patch)
2019-12-14 20:29 UTC, Alex S
no flags Details | Diff
wow64-option.patch v3 (6.04 KB, patch)
2019-12-18 03:45 UTC, Alex S
no flags Details | Diff
wow64-option.patch v4 (6.25 KB, patch)
2019-12-18 12:07 UTC, Alex S
no flags Details | Diff
wow64-option.patch v5 (6.21 KB, patch)
2019-12-18 12:37 UTC, Alex S
no flags Details | Diff
wow64-option.patch v6 (4.86 KB, patch)
2020-01-02 11:56 UTC, Alex S
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex S 2019-12-13 14:50:36 UTC
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.
Comment 1 Alex S 2019-12-14 20:29:32 UTC
Created attachment 209954 [details]
wow64-option.patch v2
Comment 2 Alex S 2019-12-18 03:45:22 UTC
Created attachment 210022 [details]
wow64-option.patch v3

+ wine version vs wine64 version sanity check
Comment 3 Alex S 2019-12-18 12:07:31 UTC
Created attachment 210029 [details]
wow64-option.patch v4

Forgot to disable WOW64 for normal (non-cross) i386 wine-devel build.
Comment 4 Alex S 2019-12-18 12:37:19 UTC
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.
Comment 5 Alex S 2019-12-31 18:46:46 UTC
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.
Comment 6 Gerald Pfeifer freebsd_committer 2020-01-02 06:39:32 UTC
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.
Comment 7 Gerald Pfeifer freebsd_committer 2020-01-02 06:44:09 UTC
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).
Comment 8 Alex S 2020-01-02 07:49:04 UTC
(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.
Comment 9 Alex S 2020-01-02 11:56:40 UTC
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.