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...)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
