Dxvk: I would like you to return the setup_dxvk.sh installation script.

[Kerrung]

Hi, @doitsujin ! Thank you for your great work!
But I would like you to return the setup_dxvk.sh installation script. It does not interfere with the simultaneous coexistence with Winetricks built-in script. But setup_dxvk.sh automatically symlinks creation are very useful for those using yaourt (or other AUR helper) to install the updates of the dxvk-bin and dxvk-git packages from the AUR. Complete abolition of setup_dxvk.sh causes inconvenience to users of these AUR packages who simply want to receive automatic updates without every times performing additional actions to update DXVK.
Thank you! Regards!

[doitsujin]

What exactly stops the AUR package from shipping the script?

[mrdeathjr28]

@Kerrung

Yes script is more usefull, specially with various prefixes

In my case:

For 32bit prefix

WINEPREFIX='/home/linuxdesktopx86/.wine/' ./setup_dxvk.sh

For 64bit prefix

WINEPREFIX='/home/linuxdesktopx86/.local/share/wineprefixes/Default-x64' ./setup_dxvk.sh

This maybe can help you for now

https://haagch.frickel.club/files/dxvk/

[tingvarsson]

I disagree with the one in #569 who stated that there was small gain in symlinking because of the file size. The gain is rather given by the fact that manual updates of ALL wine prefix's are not needed when updating dxvk (that is still very frequent) if symlinked. Combined with the fact that it is still very recommended to keep separate prefixes for different applications/games.

And since wine prefixes are not known by the package manager, it is always up to the user to manual update with winetricks then (unless there is some other magic less known which can fix it).

setup_dxvk.sh is not packaged in the official release I saw, so one has to build it manually for it to be included? For Arch specifically it has been quite handly with dxvk-bin that updates with the official releases and delivers based on that package. (no need to have the build environment setup locally which seems to be a bit messy on Arch)
On the other hand I'm pretty sure some magic can be done from the AUR package to avoid having to build the package just to get the setup script in the dxvk-bin case.

I also presume setup_dxvk.sh will perhaps not be properly maintained if this winetricks verb becomes the default.

[doitsujin]

Also, I don't really understand the rationale behind this request. The old script had multiple issues:

• Users had to invoke the script twice, and many people did not set up the 32-bit DLLs in a 64-bit wine prefix which led to a fair number of bug reports.
• Moving the files to a different location would break the symlinks.

The first point was a real issue, and the second one is just a really bad solution for a shipping release. I also feel that the "update all wine prefixes" argument only holds true if you manually copied the files to a fixed location.

Package maintainers may have liked that, but they also have the power to ship a small script which does the work for you depending on where they put the files. But the old script didn't really cover that use case either, the AUR package for example gives you setup_dxvk32 and setup_dxvk64 instead of two setup_dxvk.sh.

Also releases will be less frequent from here on in. There were a lot of bug fixes in each of the 0.6x releases, but things are more mature now and the currently known issues are not of the kind that can be fixed that easily, and I don't expect any future bug to be easy to fix at all.

I also presume setup_dxvk.sh will perhaps not be properly maintained

There's not much to maintain, and as of now I'm still using it for development builds where the fixed location is no issue, and symlinking is more desireable. I'm still looking for a way to replace it without breaking the workflow.

[Kerrung]

What exactly stops the AUR package from shipping the script?

@doitsujin
For example:
Suppose I'm a new DXVK user. I just installed the dxvk-bin AUR package.
If I have setup_dxvk.sh script, then I just run it only once and in the future I just install the dxvk-bin package updates using any AUR helper, for example
yaourt -Syua --noconfirm
and no other actions are required of me then and this is quite satisfactory for me. I may not even be interested in and check whether a new DXVK update has already been released or not, and instead I just run yaourt -Syua -noconfirm and I have no reason to care about anything else. And only if I run into any releases only then I'll go here to the official DXVK repository, read the update description, change the DXVK Wiki and write a bug report if I can not find the answer to my question in the official documentation.

But if I want to receive these automatic updates of the dxvk-bin package without having a setup_dxvk.sh script, then I have to manually do everything that the script did before, that is, manually create symlinks for each dll and manually add the corresponding overrides to winecfg.
I think that it is very obvious that it is much less convenient, especially it is less convenient for beginners than just one to run the setup_dxvk.sh script.

And the use of winetricks script does not imply any automatic updates of DXVK. I think that this approach can lead to the fact that many users will simply often forget to update DXVK.
In addition, using the winetricks script for DXVK updates forces me to run the winetricks script for updates in every single WINEPREFIX, which lead to a lot of inconvenience in cases if I have a large number of separate WINEPREFIX's.

[doitsujin]

You are describing a problem with the AUR package. If the AUR package depends on the old setup script, then the package needs to be updated, but I'm not the maintainer.

In addition, using the winetricks script for DXVK updates forces me to run the winetricks script for updates in every single WINEPREFIX, which lead to a lot of inconvenience in cases if I have a large number of separate WINEPREFIX's.

The alternative would be to break symlinks when you remove your files and leaving all your wineprefixes in a pretty much non-functioning state. Again, there is nothing stopping package maintainers from creating a small script that sets up the symlinks for you, but it simply is not a good solution for a standalone release.

[Kerrung]

You are describing a problem with the AUR package. If the AUR package depends on the old setup script, then the package needs to be updated.

@doitsujin
The problem I described is technically impossible to solve by making any changes to PKGBUILD. The AUR package simply puts the DXVK files in the /usr/share/dxvk folder and does nothing else.
And then without a script the user will have to manually create symlinks and overrides for each individual DXVK dll, and this is much less convenient than running one script once, which itself would do it automatically. If the release is that you need to run the script separately for 32 and 64, then you can improve this script so that it automatically creates symlinks at the same time for 32 and 64, or add to the script the output of a text warning about the need to run the script for 32 and 64 too.

And the use of winetricks script does not imply any automatic updates of DXVK. I think that this approach can lead to the fact that many users will simply often forget to update DXVK.
In addition, using the winetricks script for DXVK updates forces me to run the winetricks script for updates in every single WINEPREFIX, which lead to a lot of inconvenience in cases if I have a large number of separate WINEPREFIX's.

[Kerrung]

@doitsujin can you please include both in DXVK the winetricks script and the setup_dxvk.sh script at the same time?
Thank you. Regards.

[tingvarsson]

Realize we are kind of discussing a quite small issue. And like you say @doitsujin package maintainers can provide the script regardless, and when I think more about it that is probably the preferred way than having some script from upstream.
The thing it does is extremely trivial as well, symlink and DLL overrides.
Then of course it should be quite easy to solve the 32/64bit scenarios in any scripting language I believe.

[debiangamer]

doitsujin, see your setup_dxvk.sh file, it does not delete dll overrides with the reset parameter.

[doitsujin]

It does get rid of the files though. The winetricks verb will just set them up again.

[pchome]

@Kerrung

I have a large number of separate WINEPREFIX's.

for prefix in *; do
  [ -d $prefix ] && echo "Updating every single WINEPREFIX=$(pwd)/$prefix";
done

[Ravencoin-Miner]

As a lutris user who has many games and simply goes through lutris and changes the DXVK version to the latest release, how exactly would I go about updating to this release? The same way? Or do I need to do something special.

[doitsujin]

Nothing should change if you use Lutris.

[ssorgatem]

Hi.
I'm the author and maintainer of the AUR packages.

I'll find a way to keep the symlink functionality; the easiest way seems to maintain a setup script specific to the AUR packages.

I'll look into it as soon as I have some time for it ;)

[Kerrung]

Hi.
I'm the author and maintainer of the AUR packages.
I'll find a way to keep the symlink functionality; the easiest way seems to maintain a setup script specific to the AUR packages.
I'll look into it as soon as I have some time for it ;)

And so considering this @ssorgatem comment I close this thread.
Thank you!
Regards!

[ssorgatem]

It is done.

In the end, instead of maintaining the setup_dxvk.sh script, I rolled my own winetricks verbs, based on upstream. But here's the thing: they do not copy the files, they symlink them, just like the setup script did.

This is all internally, for users, you'll still have the "setup_dxvk32" and "setup_dxvk64" scripts, but they will use winetricks now.

Also, there's now a 32-bit winelib package.

[Kerrung]

@ssorgatem tell me please how I should use your script?
Show me please some commands examples.
Thank you.

[ssorgatem]

@Kerrung same as before.
setup_dxvk32 symlinks 32-bit DXVK dlls.
setup_dxvk64 symlinks 64-bit DXVK dlls.