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: Closed Not Accepted
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-06-29 04:46 UTC (History)
12 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.
Comment 10 Alex S 2020-01-26 00:59:24 UTC
(In reply to Gerald Pfeifer from comment #7)

> I'll ask other FreeBSD committers for help

So, how is that going?
Comment 11 Alex S 2020-02-01 09:06:12 UTC
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.
Comment 12 Gerald Pfeifer freebsd_committer 2020-02-01 11:42:53 UTC
(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).
Comment 13 Alex S 2020-02-01 13:13:02 UTC
(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.