user debian...@lists.debian.org
usertags 980148 + fileconflict
severity 980148 serious
thanks
Hi,
On Fri, Jan 15, 2021 at 12:06:14PM +0100, Michel Dänzer wrote:
> On 2021-01-15 12:02 p.m., Thorsten Glaser wrote:
> > Package: mesa-vulkan-drivers
> > […]
> > Multi-Arch: same
> >
> > The file /usr/share/vulkan/icd.d/intel_icd.x86_64.json differs.
> >
> > amd64:
> >
> > {
> > "ICD": {
> > "api_version": "1.2.145",
> > "library_path": "/usr/lib/x86_64-linux-gnu/libvulkan_intel.so"
> > },
> > "file_format_version": "1.0.0"
> > }
> >
> > x32:
> >
> > {
> > "ICD": {
> > "api_version": "1.2.145",
> > "library_path": "/usr/lib/x86_64-linux-gnux32/libvulkan_intel.so"
> > },
> > "file_format_version": "1.0.0"
> > }
> >
> > This file must be moved out of /usr/share and into a multiarch library
> > path.
>
> Looks to me like the filename is wrong on x32.
How do you reach that conclusion? At least the multiarch tuple is
appropriate for x32.
A similar problem exists for armel and armhf. Both install
/usr/share/vulkan/icd.d/lvp_icd.armv8l.json and
/usr/share/vulkan/icd.d/radeon_icd.armv8l.json. I haven't checked their
file contents, but it seems very likely that they differ in
arm-linux-gnueabi vs arm-linux-gnueabihf in their library_path.
Given that these files reference shared libraries, they are inherently
architecture-dependent and that makes them technically inappropriate to
ship below /usr/share. Would it be feasible to transition these files
rom /usr/share/vulkan/icd.d to /usr/lib/<triplet>/vulkan/icd.d? That'd
be a longer adventure as the consumers of these files would first have
to search both locations and once they all consider both we could start
moving them.
The file conflict on two release architectures makes the problem rc (as
you can practically experience an unpack error). A short-term workaround
is dropping Multi-Arch: same. Doing so reopens #853897 sadly.
Helmut
