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

[Goswin von Brederlow]

On Thu, Dec 27, 2012 at 01:01:43PM -0500, The Wanderer wrote:
> On 12/27/2012 11:10 AM, Goswin von Brederlow wrote:
> 
> >On Thu, Dec 27, 2012 at 10:42:16AM -0500, The Wanderer wrote:
> >
> >>With the advent of multiarch, the ia32-libs package has now been replaced
> >>with a transitional package which simply depends on the :i386 versions of
> >>the separate packages for the various libraries previously shipped as part
> >>of ia32-libs. This allows people who had been depending on ia32-libs to
> >>make a simple transition to multiarch, with little or no manual effort.
> >>
> >>Is there any corresponding or otherwise similar transition planned for
> >>ia32-libs-dev and the various libraries' development packages? Or is it
> >>intended that anyone using ia32-libs-dev will need to install any
> >>*-dev:i386 packages which they still need manually? Or are the -dev
> >>packages expected to conflict with their other-architecture equivalents in
> >>some way, such that it does not even make sense to have more than one
> >>installed at once?
> >>
> >>Put simply: what is it intended that someone who has had ia32-libs-dev
> >>installed do, in making the transition from ia32-libs to multiarch, to
> >>retain the equivalent of the functionality provided by the ia32-libs-dev
> >>package?
> >
> >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.
 
> 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 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?
 
> 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:

- Dev packages contain include files which in most cases are
architecture independent. The package should therefor be arch:all,
M-A: foreign. Otherwise you get file conflicts. [1]

- But some include files are architecture specific and belong in the
multiarch include dirs. Those need to be in an arch:any, M-A: same
package.

- Dev packages include the .so symlink. That one is architecture
specific forcing dev package to be arch:any, M-A: same.


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.

MfG
	Goswin
--

[1] The file conflicts between multiarch packages is now resolved is
that bit identical files are allowed to exist. This wasn't initially
planed.