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

[The Wanderer]

On 01/07/2013 06:03 AM, Goswin von Brederlow wrote:

> On Thu, Dec 27, 2012 at 01:01:43PM -0500, The Wanderer wrote:
> 
>> On 12/27/2012 11:10 AM, Goswin von Brederlow wrote:

>>> The right way is to use an i386 chroot to build i386 packages and use
>>> them under multiarch.
>> 
>> While that is very likely the right way to build 32-bit Debian packages, it
>> does not seem to address the question of the functionality which was
>> provided by ia32-libs-dev.
>> 
>> That package made it possible to compile against (many) 32-bit libraries in
>> a 64-bit environment, just as ia32-libs itself made it possible to run
>> against those same libraries. Compiling in a 32-bit chroot is not compiling
>> against 32-bit libraries in a 64-bit environment; it is compiling against
>> 32-bit libraries in a 32-bit environment.
> 
> Yes. Compiling 32-bit code in a 64-bit environment, or more generally
> building for a foreign architecture on a multiarch system is still a goal of
> multiarch, but one that will come in multiarch V2 if you will. There simply
> hasn't beend enough time spend on making that work and it was always
> scheduled as a second stage.
> 
> So for now we have a regression there.

Acknowledged. As long as it *is* considered a regression, and the plan is to fix
it in the long run, I can live with that.

>> Although there may not be many programs which need to be able to compile
>> and install 32-bit code in a 64-bit environment (the only one which springs
>> to mind is the full 64+32 Wine, which is in fact my primary and perhaps
>> even sole use case for this), the fact remains that it was possible to do
>> that with ia32-libs{,-dev} with no need for the overhead of a 32-bit chroot.
>> That functionality is what I would like to retain under multiarch, and the
>> procedure to transition from ia32-libs-dev to multiarch while retaining
>> that functionality is what I am asking about.
> 
> 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).

>> If the only way to retain that functionality is to install the still-needed
>> -dev:i386 packages manually, and it is intended to be possible to do so,
>> fair enough; it would have been nice to see some hint about that at upgrade
>> time (rather than simply the removal of the package), but the process
>> shouldn't be excessively onerous at least in my case. I was simply holding
>> off on the assumption that a "transitional package" version of
>> ia32-libs-dev would be forthcoming.
>> 
>> If on the other hand it is *not* intended to be possible to have both
>> -dev:amd64 and -dev:i386 packages installed and usable in parallel, and no
>> alternative is being provided - i.e., the functionality formerly provided
>> by ia32-libs-dev is being intentionally dropped - it's possible the
>> decision to drop that functionality might be justified... but in that case,
>> the fact of the decision that should be explicitly stated. (And of course,
>> I'd like to see the justification, if possible.)
> 
> Eventualy it is supposed to work that you simply install -dev:i386. But that
> can't work for the moment. Here is why:

<snip>

Since my last mail, I discovered the "MultiarchCross" and
"CrossCompile/UsingMultiarch" pages on the Ubuntu and Linaro wikis respectively,
and they explained the basics of the idea here. They haven't been touched in
some months, but if they're still accurate, that's fine enough. I'll just have
to stick with ia32-libs-dev until the process is complete.

I don't really consider "i386 on amd64" to be cross-compiling (although the
reverse probably would be), since you can run the result in the host system just
fine. I can see where the problems to be solved would be largely the same,
though.

> To do it right nearly all -dev packages would have to be split into -dev and
> -common-dev. Most of the time leaving only the symlink in the -dev package.
> This would have added a ton of new packages and left a ton of packages with
> just a symlink in them. And there were already too much grumbling about the
> package count increase for the other packages.
> 
> Also not all cross-compile issues under multiarch have been resolved and put
> into specs yet. The -dev packlages would so far only work for i386/amd64 and
> basically just for wine and one or two other sources.
> 
> Therefore -dev packages were delayed for a 2nd stage. To be done when
> multiarch was established for binaries and libraries.

Acknowledged.

Any idea of an ETA on this? Obviously it won't be done for wheezy; it it planned
for jessie, or is it likely to slip beyond that, or...?

Is there anything I could do to help with getting it done, if I have time among
my other projects? Or is this mostly something only the maintainers of the
affected packages can make progress on?

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