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
