Package: libopenxr1-monado
Version: 21.0.0+git2905.e26a272c1~dfsg1-2
Severity: normal

To reproduce:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libopenxr1-monado libopenxr1-monado:i386

Expected result:

Successful installation

Actual result:

dpkg: error processing archive ….deb (--unpack):
trying to overwrite shared '/usr/share/openxr/1/openxr_monado.json',
which is different from other instances of package
libopenxr1-monado:i386

Mitigation: VR games have sufficiently high performance demands that
running them under emulation, or compiling them for a legacy ABI like
i386, is unlikely to be practical, so there is no urgent need for
multiarch co-installation to be possible.

This is a Debian Policy violation, but because of the mitigation, I'm
not reporting this bug as RC (although someone with a stronger opinion
might raise its severity).

There are two ways this could be made to work, and the JSON manifests
for Vulkan drivers (which have a similar structure) provide examples of
each way.

1. Have a single JSON manifest /usr/share/openxr/1/openxr_monado.json,
and ensure that its contents are identical for every architecture.
Make /etc/xdg/openxr/1/active_runtime.json a symlink to this.

The Nvidia proprietary driver as packaged in Debian non-free takes an
approach similar to this for its Vulkan driver: nvidia-vulkan-common
contains /usr/share/vulkan/icd.d/nvidia_icd.json which refers to

"library_path": "libGLX_nvidia.so.0",

which is searched for in the default dlopen() library paths, and
resolves to an appropriate architecture-specific location like
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 for each architecture.

For Monado, this would probably require either giving the upstream
build system an option to request this setup, or applying some
`sed -i` to the JSON manifest in debian/rules.

2. Have a separate JSON manifest for each architecture, which can have
architecture-specific contents if needed.
Make /etc/xdg/openxr/1/active_runtime.x86_64.json a symlink to the
manifest for amd64, and so on. This would require a lookup table
mapping each Debian architecture (such as amd64) to its corresponding
OpenXR architecture name (such as x86_64); there is a table in the
OpenXR spec.

The Mesa Vulkan driver as packaged in Debian main takes an approach
similar to this: each architecture instance of mesa-vulkan-drivers
contains files with names like
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json, each of which refers
to the appropriate architecture's driver library with a path like:

"library_path": "/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so",

(2.) is fine for Vulkan, but would be awkward for OpenXR because it
would require more elaborate machinery to maintain multiple
active_runtime symlinks, so I think (1.) would likely be a better choice
for how OpenXR runtimes are managed in Debian.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ah, so that's why it's broken... Sorry I had missed that, hadn't looked
at the actual contents of the manifest in a while.

I can actually just fix that with a CMake flag to tell it to spit out a manifest containing only the SONAME, which is what I thought it was
doing already.

I'll include a fix in my upcoming upload.

Thank you!

Rylie

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRfNC4kmZNxSd8U/4TSLuqR2qJ8yAUCaAk6EQAKCRDSLuqR2qJ8 yKbnAP401SWMJoySqqTTzTqLMhvxnRzB+B7Bn2g9efcP/GqmtwD6A0pkVa+hgTlV Yxa4HhaJT7ozdIDUslwTG2V39jl4Hgs=
=NDWg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)