[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Depends: libfoo:foreign ???



On Mon, 13 May 2013 11:43:05 -0400, The Wanderer <wanderer@fastmail.fm> wrote:
> On 05/13/2013 11:00 AM, Wookey wrote:
> > OK. And is 32-bit wine (to be installed on amd64) an amd64 binary
> > that understands i386 code or is it actually i386 code? If the latter
> > to what degree are wine32:amd64 and wine32:i386 any different?
> 
> To the best of my ability to determine, it is the latter.
> 
> On a per-file level, I don't actually know that they are different, and
> what investigation I've done seems to indicate that they may not be. On
> a package-wide level, some components which get built and installed
> during a standalone 32-bit build don't get built for a combined build,
> because they are covered by components provided by the 64-bit build.
> (The same also appears to be true in reverse.)
> 
> > Do we actually (ideally perhaps) just have 2 things:
> > wine64:amd64  (amd64, amd64, win64)
> > wine32:i386   (amd64, i386, win32)
> > 
> > or three things:
> > wine64:amd64  (amd64, amd64, win64)
> > wine32:amd64  (amd64, amd64, win32)
> > wine32:i386   (amd64, i386, win32, if cross-built) (i386, i386, win32, if
> > native-built)
> > 
> > where:  (Build, Host, Target) means: Build is the arch built on, Host
> > is the arch it runs/is installed on, and target is the code/abi
> > '(not)-emulated'
> 
> The "three things" case seems almost accurate, except for one thing:
> wine32:amd64 would be targeted to install on an amd64 host, but would be
> i386 code. That may be what you intended, but I don't see it implied by
> the above statement.

The upstream approach would be "three things", using multilib rather than
multiarch for the wine32:amd64 packages and native building for the i386
packages. It may be possible to support the "two things" approach using
multiarch, but it would make life a bit harder for maintainers and would
introduce yet another change from upstream (but if multilib disappears in
favour of multiarch we'd need to do it anyway). Mike Gilbert is working on
all this just now, he'd be the one to ask!

Regards,

Stephen

Attachment: signature.asc
Description: PGP signature


Reply to: