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.
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.
(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.)
--
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5190d4b2.2030...@fastmail.fm
