Bug#540646: [libwine-unstable] wine.bin cannot find libwine.so.1

[Ove Kaaven <ovek@arcticnet.no>]

Aurelien Jarno skrev:
> On Sun, Aug 09, 2009 at 10:21:05PM +0200, Ove Kaaven wrote:
>> Aurelien Jarno skrev:
>>> biarch packages should not use the multiarch path, otherwise the
>>> transition to multiarch would be a nightmare.
>> So how do you propose I multiarchify Wine (and make it ia32-apt-get-able
>> while I'm at it) without using multiarch paths?
> 
> You can use the multiarch paths, but only with the path corresponding to
> the architecture of the .deb that is:
> - /usr/lib/i486-linux-gnu on i386
> - /usr/lib/x86_64-linux-gnu on amd64
> - etc.

That won't help. Even if it had made any sense to put 32-bit libraries
into /usr/lib/x86_64-linux-gnu, I've done these changes for a reason.
For Win64 support, I need a path to place the 32-bit Wine libraries as
well as a path to place the 64-bit Wine libraries, simultaneously and
nonconflicting. Preferably paths that ld.so will also actually search.
It turns out that using different library paths in the i386 and amd64
build (/usr/lib on i386 vs /usr/lib32 on amd64) is going to break under
the likes of ia32-apt-get (and, of course, under real multiarch) since
the correct path must be compiled into libwine, and the only path I know
that is supposed to work the same on i386 and amd64 for holding 32-bit
libraries is /usr/lib/i486-linux-gnu.

Hence I've multiarchified Wine, and as a temporary measure until real
multiarch is here, I still build amd64 packages with i386 content
inside. Once multiarch is here, and the user can install the i386
packages directly, *then* I'll switch the build system to only build the
64-bit content into the amd64 packages, and make it the user's
responsibility to coinstall the 32-bit and 64-bit packages. (And try to
avoid holding up any transitions.) Until that's possible, I need a way
to ship 32-bit and 64-bit libraries from the same packages, making the
package conform to the upcoming multiarch stuff seemed like a reasonable
solution, and de-multiarching the package (and be back at square one)
again doesn't really seem appealing...