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

[Goswin von Brederlow]

On Tue, Jan 08, 2013 at 09:38:50AM -0500, The Wanderer wrote:
> On 01/08/2013 04:30 AM, Goswin von Brederlow wrote:
> 
> >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.
> 
> While possibly true, that doesn't help with people who are wanting to build wine
> themselves, e.g. to track git (and possibly even contribute to development). At
> best, it means they have to deal with two previously-unnecessary intermediary
> elements of the build process: the 32-bit chroot and the building - and then,
> later, installing - of Debian packages.

They would have to build a pure 32bit wine, a pure 64bit wine or both
depending on what they want to test.
 
> >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.
> 
> I've just looked over the source (or at least the build system), and I don't see
> any way in which it alters anything which actually does get built, although
> there are a few more things than just wineserver which are used from the 64-bit
> side in the -with-wine64 case (tools, fonts, and apparently man pages being the
> only ones I've noticed so far).
> 
> There may still be a problem, however, due to the use of that tools/ directory.
> Those tools appear to be used during the actual build process, and the
> --with-wine64 build simply reuses the ones built during the -enable-win64 build;
> naturally enough, those tools are 64-bit, and dynamically linked.
> 
> If those tools are needed during the build process, which they appear to be,
> then the --with-wine64 build likely won't work properly in a strictly 32-bit
> environment. An i386 chroot may not be a "strictly" 32-bit environment (in that
> it's still hosted on a CPU and under a kernel which can handle amd64 code), but
> since the tools are dynamically linked, they may fail anyway.

You wouldn't use --with-wine64 at all. You build a pure 32bit wine on i386,
a pure 64bit wine on amd64 and then install the packages you want.

I'm assuming the 32bit wineserver (and other tools) would work just as well
as the 64bit ones for a 32/64 wine, too. Otherwise the depends would get a
bit more complex to ensure you always get a 64bit wineserver under multiarch.

> Two other things.
> 
> One, from the fact that you didn't reply to my question about it I infer that
> there is in fact nothing in particular I could do to help out with the
> multi-arch -dev transition.

Not for this release anyway. After that the sky is the limit.
 
> Two, is there a reason why I am receiving your replies only directly to myself,
> rather than (either also or exclusively) through the list? I'd prefer to receive
> them through the list, and I have "suppress duplicates" turned off everywhere I
> can find on my mail provider's side, but I don't seem to be receiving the
> allegedly duplicate copies which should have come through the list. (Although I
> do receive copies of my own messages.)

Hmm, I might have hit the wrong key and not done a list reply. Sorry, new
email client I'm testing.

MfG
	Goswin