Quack,
Sorry for not replying earlier. I wanted to have a better look at your
changes first and it took me a while to get some time.
On 2025-01-07 23:11, Simon McVittie wrote:
Do you mean you prefer the way I packaged it, with a single source
package
that builds both DXVK Native (on all architectures) and DXVK-for-Wine
(on Windows architectures)?
Or do you mean you'd prefer two separate source packages?
I think a single package is fine and only if it proves to be problematic
then we'll split as a final resort.
Perhaps? The risk is that Debian's version of mingw-w64 could be either
too new or too old, breaking assumptions made by DXVK or by DXVK-based
games.
The upstream build system installs the headers (they become part of
DXVK's API), but it would probably be possible to replace them with a
directory containing symlinks to the same curated subset of Debian's
version of mingw-w64-common, or something like that.
I did not realize that it recreated another API. In my mind the API is
defined by DirectX and any deviation is a bug in DXVK. That's why a
newer one would surely fix problems so if the Debian package we base it
on is updated properly then it should work.
I'm not happy about this but let's vendor it and then we can see if the
next release cycle if we can do better.
We do publish the source code for all packages in the Steam Runtime as
.dsc to make sure we meet our (L)GPL obligations, but we don't
generally
publish the git repositories for arbitrary packages (it's just a lot of
code, most of which we patch trivially or not at all, so the
cost/benefit
ratio doesn't look great). I could probably mirror our src:dxvk onto
Salsa
for reference if you're interested?
It's kind to propose it but it's fine for now.
It is technically possible to use the Steam Runtime as a separate thing
without going via Steam, but I'm not aware of any non-Steam games that
use DXVK Native in practice, and as a semi-self-contained binary
distribution it doesn't really help you to test a pure Debian setup.
I discovered Lutris is using umu which is based on the Steam Runtime,
which can be handy for games that do not work with Wine+DXVK+VKD3D (the
original VKD3D I mean). I have no idea if that's using DXVK Native
inside but it's apparently vendoring everything so I won't be able to
use the new libraries in the dxvk package.
The examples I borrowed from @misyltoad for the autopkgtest are really
just a smoke-test, but they're the best I currently have for DirectX
branches other than 9. I've heard that native Linux games based on FNA
are
likely to require DXVK Native in future (not sure which DirectX
branch),
but I don't have any concrete examples right now: the FNA maintainer is
waiting for us to integrate SDL 3 into the Steam Runtime, which in turn
is waiting for SDL upstream to declare it to be stable.
Alright, so I guess I could simply release new versions and upload as
long as the basic tests work, and we'll add more later if we can, then
may I leave it to you to do more testing on your end and report problems
you encounter?
For `libdxvk_d3d9.so.*`, my test targets for the Steam Runtime are
currently all Valve games that require Steam: Team Fortress 2, Portal
1,
Portal 2, Left 4 Dead 2. TF2 is free-as-in-free-beer if that's any
help?
Some unsupported tinkering is currently required to make those games
use a DXVK version other than the one that they bundle, although
they'll
most likely switch to relying on the Steam Runtime's copy of DXVK next
time their Linux ports get a significant update.
I prefer to use games without DRMs, that's why I do not have a Steam
account and I would not be able to test them.
I looked at your changes and I have a few questions:
- why are the dh_auto_* steps in execute_after_* instead of
override_*? IIUC they will be run twice. Since you gate the change with
a filter on the built packages that does not seem necessary to use
`after`. did I miss something?
- would you mind having the headers bundled into subprojects /
vendor.xz? honestly I would prefer if the debian/ diff would only show
useful packaging bits.
Once the above is cleared, would you mind preparing a PR on top of 2.6-1
that I just uploaded?
Regards.
\_o<
--
Marc Dequènes
