Steve Langasek wrote:
Wow. No, definitely not. If the package can't be built on amd64, I'm not ok with shipping binary blobs that get unpacked this way. What are the difficulties with building 32-bit wine on amd64?
There are not enough 32-bit libs on amd64 to satisfy all of Wine's core build dependencies. For example, it needs libicu36 for proper i18n support. Since ICU gets statically linked into Wine, a "binary blob" built on i386 can have i18n support on amd64 even though libicu36 does not otherwise exist in 32-bit form on amd64.
I'm also concerned that a few X11-related libraries do not have .so symlinks in ia32-libs. For example, libXmu.so.6 exists there, but libXmu.so doesn't, which would make linking against it impossible if it was built on amd64, even though it's there at runtime.
For what it's worth, I'm also wondering whether the amd64 version of prelink does anything useful on a 32-bit application. (Wine depends on an explicit prelink pass to counter certain kernel security patches that might otherwise interfere.)
Numerous other libraries, such as CUPS, SANE, JACK, SSL, DBUS, gphoto, etc, do not exist in 32-bit form. This is admittedly no argument against building on amd64, since the Wine components that depends on these cannot function anyway without having these libs at runtime - but the control and rules file might have to undergo some intrusive changes to avoid building these components (and associated empty and useless libwine packages), a more dangerous change than just building a binary blob, and one which may be more difficult to peer-review and trust.
For me, the ICU issue was the most important factor.(Well, in addition to not wanting to deal with the maintenance issues of explicitly not building a bunch of libwine packages on amd64 until more 32-bit libraries suddenly appear - I don't even use amd64, so I wouldn't track its progress. But that's my problem, of course...)