Re: Depends: libfoo:foreign ???
On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote:
> On 05/09/2013 11:59 AM, Wookey wrote:
>
> >+++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
>
> >>I would say that a foreign dependency on a library is never right.
> >
> >That's too strong. It can make sense for cross-tools, or maybe
> >emulators, which genuinely need a foreign-arch library to operate.
> >But I'm not aware of other sensible usages.
>
> If I'm correctly understanding what's being described here, I would
> think that the full-functionality 64+32 Wine would probably be another
> exception (unless it falls under "emulators", in which case "another"
> doesn't apply); the 64-bit side is built against and depends on 64-bit
> libraries, and the 32-bit side is built against and depends on both
> 32-bit libraries and the already-built 64-bit side, and both sides are
> needed for an install capable of handling both 32-bit and 64-bit Windows
> programs.
>
> I don't see any practical way to let a package providing the
> full-functionality 64+32 Wine work without depending on both the 64-bit
> (native) and the 32-bit (foreign) libraries.
Wouldn't that be 64-bit + 32-bit binaries? I thought wine had seperate
binaries and a wrapper that picks the right one to start.
Wine depends on wine-bin:i386 or wine64-bin:amd64 (similar for
kfreebsd). The arch qualifier is not needed since the right thing
already happens (normaly).
Except there is wine-bin:powerpc. That kind of ruins that. A system
with amd64, i386 and powerpc configured would hapily use
wine-bin:powerpc instead of wine-bin:i386. Or wine-bin:i386 can be
used instead of wine-bin:kfreebsd-i386. But that is a matter of pining
the architectures corectly.
> >>If the source compiles binaries for the foreign arch then the
> >>package should be build on the foreign arch directly. Period.
> >
> >Apart from the above exceptions, I agree.
>
> For the full 64+32 Wine, I don't believe this is possible - or if it is
> possible, no way of doing it has yet been documented that I know of. The
> official Wine documentation of how to build that configuration involves
> compiling the 32-bit side on the same 64-bit host as the 64-bit side -
> and, importantly, compiling it against the already-built but
> not-yet-installed 64-bit build tree.
>
> Theoretically it might be possible to build the 64-bit side on an amd64
> machine, make the resulting tree available to an i386 machine, let the
> i386 machine compile the 32-bit side against the 64-bit tree, make the
> resulting tree available to the amd64 machine again, and let the amd64
> machine do the final 'make install' or equivalent process. I wouldn't
> expect that to actually work, though, given that it looks like the Wine
> "tools" built on the 64-bit side may get run during the 32-bit side of
> the build - and even if it does work, that seems like far more trouble
> than should be justifiable for what is otherwise a straightforwardly
> scriptable build process.
That seems to be a problem in the wine build system though. It should
already be possible to build a 32bit only wine and a 64bit only wine.
And then you just need something to build the extra tools that chose
between 32bit and 64bit. Or not?
I don't know the wine build system so I can't say how much pain that
would cause. But it would be the most logical way.
> (This is the main use case I have for multi-arch -dev packages; without
> them, the only way I can think of to potentially accomplish a full 64+32
> Wine build which I would expect to result in full functionality is to
> identify all -dev packages needed for the desired Wine library support,
> then pause in between build stages to manually swap which architecture
> of each of those -dev packages is installed - and swap back afterwards
> for normal compilation of other things.)
Shifting the build tree around between amd64 and i386 and back to
amd64 is no solution. That will never fly.
If the two archs can't be build seperately then I guess you will have
to encourage maintainers to make their -dev packages coinstallable
quickly for jessie. And get support for Build-Depends: libfoo-dev:i386
[amd64] added.
MfG
Goswin
Reply to: