Arch Linux User Repository

To enable DXVK in a wineprefix, do the following (with the WINEPREFIX variable properly set):

setup_dxvk install

In order to uninstall DXVK from a wineprefix:

setup_dxvk uninstall

@ssorgatem

The moment a change needs to be done to it (which will eventually come)

That script has largely remained the same for the lifetime of the dxvk project. There have been updates, some contributed by myself, but there all were improving robustness. None of them has changed the functionality itself. Given this history, I find it highly unlikely for it to require any change that isn't as simple as a sed command.

But it leads to code duplication between the several DXVK packages.

You are substituting a 2-line addition to 5 package, with the creation of a new package and the updating of the same 5 packages to list it as a dependency. Even if I don't elect to use that -common, because of fear that the maintainer of it might not respond in time when the aforementioned need for changes might occur, I will still need to update my packages to conflict with the -common package. Therefore I still believe it is unnecessary inconvenience and pollution.

-common packages in repos are usually reserved for larger size assets, not 5KiB scripts.

@loathignkernel using the static link for the file before that commit or just a patch reverting that commit only allows us to use the script unmodified. The moment a change needs to be done to it (which will eventually come) we'd need to drop that and at the very least include the file itself as a source file. So between reverting the commit and providing our own file, only the latter is future-proof.

But it leads to code duplication between the several DXVK packages. If several packages share some files, I don't see how making a separate package of them to remove duplication is any "pollution". There's plenty of "-common" packages in the official repos and in the AUR that are exactly that.

@kekonn From the moment you are packaging a project in a way that upstream doesn't do it themselves, like here for example (you are putting it in a system-wide directory, upstream doesn't mention anything about packaging it this way) you already contradict your statement. As packagers we are obligated to an opinion on how we are going to package. Even in the official repos packages are patched beyond what upstream does, their build options change, the libraries they are linked to change. Putting it in a separate package is pollution.

Personally I think opinions belong upstream and a package should be nothing more than an install/build script. So I am all for putting this in a separate package.

Thanks for the fix!

@rfried

Unless someone re-writes the history of the repository and force-pushed to it, no the link won't ever change. The link is not for the commit's diff, it is for the repository as a whole at that point in history. (changed the link in the original comment so it can be used with wget or curl directly)

git revert reverts the commits referenced by the SHA it takes as an argument, those two commits only contain the changes that removed the script. Nothing else will be changed.

@ssorgatem) Thanks a lot

@loathingkernel) Does the github raw link points (only) to the commit 4f90d7bf5? So revert case maybe ok. But all updates later on, will be missed?

@ssorgatem

maybe it's worth exploring the option of making it into its own separate package,

This is an utterly nonsense solution, creating a separate package for a 200-line script. Source packages can git revert the two commits that removed it, and this package can directly download from the latest commit on github that included it by adding this link to the source array https://raw.githubusercontent.com/doitsujin/dxvk/4f90d7bf5f9ad785660507e0cb459a14dab5ac75/setup_dxvk.sh.

You are complicating things for no reason or tangible gain.

@wioo you are right, forgot about the symlink. Should be fixed now.

Hi, ssorgatem. looks like "../" needs to be removed from "../setup_dxvk.sh".