Newer Fedora packaging under review in https://bugzilla.redhat.com/show_bug.cgi?id=2152207, which unifies the Wine and native packaging for DXVK, seems to be using dxvk-d3d9.pc and dxvk-d3d10.pc instead, so the dependency would be dependency('dxvk-d3d9 >= 2.1'). Is that an intentional or unintentional change?
We'd had it provide the old name using pc Provides, so probably the unintentional part is not having that Provides if it's not already there.
OK, sounds good. Expecting dependent projects to check for dxvk-d3d9 etc. seems more normal to me, so I'll go with that unless the project maintainers specifically prefer dxvk-native-*.
From discussion on #3322, it seems that DXVK Native is not yet considered to be fully API- or ABI-stable (for example https://github.com/doitsujin/dxvk/issues/3322#issuecomment-1491919970 would be an ABI break), so it might be premature to be packaging it in distros or the Steam Runtime (@Joshua-Ashton, if you disagree with that assessment, I'll leave it to you to negotiate with @doitsujin about what the stability level is.)
I'm going to continue to prototype packaging in the hope that I can catch any other issues that block API/ABI stability before it's too late to change them, but I won't push for its inclusion in Debian or the Steam Runtime for the time being.
When building a native library for Linux, it's conventional to install header files to a subdirectory of /usr/include, and install pkg-config metadata describing how a dependent project can make use of the library.
In the case of DXVK, the current Fedora packaging https://src.fedoraproject.org/rpms/dxvk-native/tree/rawhide (which is somewhat outdated, currently still on 1.9) has added
dxvk-native-d3d9.pcanddxvk-native-d3d11.pc, which lets a dependent project use dependencies likedependency('dxvk-native-d3d9 >= 1.9')or their build system's equivalent to learn the right include directories, libraries and recursive dependencies.Newer Fedora packaging under review in https://bugzilla.redhat.com/show_bug.cgi?id=2152207, which unifies the Wine and native packaging for DXVK, seems to be using
dxvk-d3d9.pcanddxvk-d3d10.pcinstead, so the dependency would bedependency('dxvk-d3d9 >= 2.1'). Is that an intentional or unintentional change?DXVK Native isn't currently packaged in Debian at all (Debian only builds the Wine-compatible version), but I'm looking into updating the packaging to also build DXVK Native, similar to what's planned in Fedora. I'd like to make the Debian packaging consistent with what's in Fedora so that the same source code can work in both places, ideally via the upstream project installing the necessary headers and pkg-config itself.
Does the upstream project have a preference for what its "official" name is, when used as a Linux library by games like Portal 2?
cc @Conan-Kudo @flibitijibibo @Joshua-Ashton