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

[The Wanderer]

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.

> 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.


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.

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.)

-- 
    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger