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

[Ove Kaaven <ovek@arcticnet.no>]

Aurelien Jarno skrev:
> ia32-apt-get is gone, so I am not sure trying to support it is a good
> idea.

It might come back. Or something like it, perhaps.

>> 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
> 
> How are you going to handle this transition then? With the current
> situation, wine-unstable will provide the same file in the i386 package
> and the amd64 package (as the amd64 one already provide
> /usr/lib/i486-linux-gnu), so you will have to play with
> cross-architectures conflicts.

Well, I was thinking about handling it by just stop putting the i386
content into the amd64 packages once multiarch works. Any coinstallable
packages are automatically kept in strict lockstep by the multiarch
implementation itself, no need to worry about that. All my interpackage
dependencies are also already strictly versioned. And if I decide to not
set the Multi-Arch field (or if I use Multi-Arch: foreign/allowed) until
I remove the i386 stuff from the amd64 packages, then that by itself
would work as a perfectly suitable cross-architecture conflict.

Hence, to get breakage, someone would probably have to actively try to
get it - which, while probably possible, is a smaller concern to me than
those many who *aren't* actively trying to get breakage, but get it
anyway because of all these breakages and transitions in amd64 -
apparently including this prohibition of actually using multiarch features.

>> 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...
> 
> Don't put the libraries not conforming to the architecture of the
> package in the multiarch path. You can chose /usr/lib32 or an other
> path providing you add it to /etc/ld.so.conf.

So you *are* asking to de-multiarch the package?