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: noShould 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.