Control: retitle -1 dxvk: please package DXVK Native now that it has a stable ABI Control: tags -1 + patch
On Tue, 28 May 2024 at 20:58:02 +0100, Simon McVittie wrote: > At the moment DXVK Native's ABI is not stable and the libraries don't > have a proper SONAME, but the next release after 2.3.1 (2.3.2? 2.4.0?) > is meant to have proper SONAMEs like libdxvk_d3d9.so.0, and install > development files and pkg-config metadata in the conventional way. This has now been released: version 2.4 was the first to have a stable API/ABI for DXVK Native. > I was asked for .deb packages of DXVK as part of my work with the Steam > Runtime, and based them on the dxvk packaging in Debian. For the moment > this has to be based on a git snapshot, but I'll try to upgrade it to > a real release when available. Commits can be fetched from here: > > https://salsa.debian.org/smcv-guest/dxvk wip/dxvk-native I've force-pushed to that branch with packaging of DXVK Native for v2.4. > I'm unsure whether this would be better as additional .deb packages from > src:dxvk, or as a separate source package src:dxvk-native that happens > to have the same upstream source code. I've prototyped it as an extension > of the existing src:dxvk, with: > > * Package: libdxvk-dxgi0 > * Package: libdxvk-d3d9-0 > * Package: libdxvk-d3d10core0 > * Package: libdxvk-d3d11-0 > * Package: libdxvk-native-dev (-dev files for all of the above) In addition to those, v2.4 adds libdxvk-d3d8-0, a D3D8 implementation corresponding to d3d8.dll. > I hope those binary packages seem reasonable to the dxvk maintainers? > If possible I'd like to keep Debian and the Steam Runtime compatible > with each other. I'm still aiming to make the Steam Runtime compatible with Debian if possible. > If DXVK Native is merged into src:dxvk, then the parts that need > wine{32,64}-development should maybe be restricted to only be built > in experimental or something (there is code for this in src:openjk), > to let DXVK Native migrate to testing without being blocked by those. That would bypass #982159. I'm happy to offer advice on that if desired. > Or it could be a separate source package to allow for separate migration. That's still an option, of course. > The prototype linked above uses a `meson dist` tarball which incorporates > the vendored libdisplay-info and the vendored MinGW, SPIRV and Vulkan > headers. For packaging in unstable you would presumably want to de-vendor > at least the SPIRV and Vulkan headers, and maybe the others too, which > would require partially or fully reverting my commit "Use upstream > vendored subprojects in a `meson dist` tarball". The updated branch for v2.4 de-vendors SPIRV and Vulkan like the existing Debian package, and adds the necessary vendored copy of a curated subset of mingw-w64 headers (which are not required by the Windows DLLs, but *are* required by DXVK Native). Any opinions? Thanks, smcv
