[Pkg-ia32-libs-maintainers] ia32-libs-dev transitional package?

[Goswin von Brederlow]

On Mon, Jan 07, 2013 at 08:46:48AM -0500, The Wanderer wrote:
> On 01/07/2013 06:03 AM, Goswin von Brederlow wrote:
> >I'm not familiar with 64+32 wine but it was my impression that you would have
> >a 32bit wine (build on i386) and a 64bit wine (build on amd64) and maybe a
> >small wrapper script that picks the right one depending on the command being
> >started. Is that wrong?
> 
> Sort of.
> 
> You do end up with both 64-bit and 32-bit Wine, in the forms of 'wine' and
> 'wine64' executables, but you don't end up with a discrete wrapper that I'm
> aware of. Instead, if you launch the wrong one (e.g. trying to run a 64-bit
> program in 'wine', or presumably a 32-bit one in 'wine64'), it seems to
> seamlessly switch over to the other.
> 
> The build process for 64+32 Wine is:
> 
> * Compile 64-bit Wine in one build tree, with '--enable-win64'.
> * Compile 32-bit Wine in another build tree, against the already-built 64-bit
>   build tree, with '--with-wine64=/path/to/64bit/build/tree'.
> * Install 32-bit Wine from its build tree.
> * Install 64-bit Wine from its build tree.
> 
> See http://wiki.winehq.org/Wine64 for most of the available details.
> 
> The end result is that you get some things installed from only one build and
> some things from both. For example, you get only the 64-bit 'wineserver' (it
> doesn't even build the 32-bit one AFAIK), but you get both the 32-bit 'wine' and
> the 64-bit 'wine64'.
> 
> The second step - compiling 32-bit Wine against the 64-bit build tree - is what
> I'm not sure I see a way to do in the chroot-based approach. All I can think of
> is to place the 64-bit build tree in a path which will end up being located
> inside the chroot, and even then I can still think of potential reasons why it
> might not work - toolchain issues, for example, or a need to run some of the
> 64-bit code during the 32-bit build. However, I'll admit that I haven't tested
> that approach, since I haven't yet found a convenient way to create
> user-accessible chroots (as opposed to the temporary ones used by e.g. pbuilder).

Seems more like the wine package should be split into wine and wineserver. The
former would be M-A: same and the later would be M-A: foreign.

I'm assuming the --with-wine64 only excludes some stuff from being build and
doesn't alter the stuff that actualy does get build. But that is just a guess.

MfG
	Goswin