Re: Depends: libfoo:foreign ???
On 05/14/2013 09:34 AM, Goswin von Brederlow wrote:
On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote:
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.
It does have separate binaries, but although I'm not an expert on the
Wine software architecture, AFAICT it doesn't have a wrapper; rather, in
a combined build, each binary will apparently detect what kind of
program you're running and either handle things itself (when the
architectures match) or transfer things over the other binary (when they
don't).
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.
I'm afraid I don't quite understand what you're talking about here. Or
rather I think I do, but I don't see why you would have mentioned it at
this point, so I suspect I may be wrong.
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.
As far as I can tell, there are no extra tools; it's all integrated into
the usual Wine binaries. I could be wrong about that, but I haven't seen
anything which seems to indicate such.
The real question is the one you posed in your other mail: can you
assemble a working combined install (with functionality equivalent to
the as-documented combined build) from the results of two separate
standalone builds, by correctly selecting which files from each side to
install, or are there actual important (functional) differences in the
binaries created by a combined build?
I'm running the builds to try to test that now, but it's not clear how
long it will take to come up with an even vaguely reliable answer. I'll
provide what information I come up with when I have it.
(If this becomes specifically about Wine, it may not any longer be
really on topic for -devel; if there would be a better place to discuss
it, I'd be willing to move the discussion, but if this is considered
sufficiently on-topic I don't have a problem with continuing it here.)
(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.
Yes, of course; that was my point in mentioning it. (Assuming that by
"build tree" you mean "build environment", since swapping out installed
-dev packages shouldn't affect anything inside the build tree itself.)
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.
That was part of my goal in suggesting that completion of multi-arch
-dev support (which I envisioned to include the implementation of such
in a sufficiently broad swath of packages) be one of the release goals
for jessie.
--
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
Reply to: