Not sure if i interpret the debian multi-arch thingy right tho, but from
what i gather -
Multi-Arch: no
*
The package is *not* co-installable and it must *not* be used to
satisfy the dependency of any package of another architecture than
its own.
Multi-Arch: foreign
*
The package is *not* co-installable and *should* be allowed to
satisfy the dependencies of a package of another architecture than
its own.
Since this package afaik would not be needed as a dependency of another
package from another architecture, i think the correct way would be to
use "no". Without really being able to test this in any useful way, i
would think that the 32-bit compiler would need the 32-bit libraries to
work?
vkd3d-compiler: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=6478cd8eb2aabfb042893e17725249dbe49df3d3, for GNU/Linux
3.2.0, stripped
vkd3d-compiler: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=4729d93470ddb66db274c7b2ff5339daf7c94a77, for GNU/Linux
3.2.0, stripped
32-bit when compiled in the i386 package, and 64-bit when compiled in
the amd64 package, thus the error message when you try to install them
both. If any package would use this binary as a dependency, i would
think it needs to be arch dependent.
Sveinar Søpler
On 03.03.2021 15:38, Francois Gouget wrote:
On Wed, 3 Mar 2021, Sveinar Søpler wrote:
I actually ended up generating a "vkd3d-tools" package for my Ubuntu
PPA packages with this binary set to Multi-Arch: no
Should that actually be Multi-Arch: foreign?
Just asking. I don't actually know if the 32- and 64-bit vkd3d-compiler
produce identical files or if one produces 32-bit files and the other
64-bit ones.
If the latter then following the gcc naming scheme would probably make
sense.
