Package Details: dxvk-bin 2.3-1

Git Clone URL: https://aur.archlinux.org/dxvk-bin.git (read-only, click to copy)
Package Base: dxvk-bin
Description: A Vulkan-based compatibility layer for Direct3D 9/10/11 which allows running 3D applications on Linux using Wine (Windows DLL binary files)
Upstream URL: https://github.com/doitsujin/dxvk
Keywords: dxvk
Licenses: zlib/libpng
Conflicts: d9vk, dxvk
Provides: d9vk, dxvk
Submitter: ssorgatem
Maintainer: ssorgatem (kekonn)
Last Packager: ssorgatem
Votes: 221
Popularity: 1.81
First Submitted: 2018-03-02 07:39 (UTC)
Last Updated: 2023-09-08 07:27 (UTC)

Dependencies (2)

Required by (4)

Sources (2)

Pinned Comments

ssorgatem commented on 2018-03-27 06:47 (UTC) (edited on 2019-02-26 12:20 (UTC) by ssorgatem)

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

Latest Comments

1 2 3 4 5 6 .. 15 Next › Last »

begin-theadventu commented on 2024-03-15 13:17 (UTC) (edited on 2024-03-15 13:50 (UTC) by begin-theadventu)

Proposal: p̶k̶g̶b̶a̶s̶e̶, license: zlib-acknowledgement, source for setup_dxvk.sh (last commit before it got removed), 17->16, package_dxvk-bin -> package

loathingkernel commented on 2023-02-13 08:19 (UTC)

@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.

ssorgatem commented on 2023-01-26 08:53 (UTC)

@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.

loathingkernel commented on 2023-01-25 18:52 (UTC) (edited on 2023-01-25 18:53 (UTC) by loathingkernel)

@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.

kekonn commented on 2023-01-25 18:33 (UTC)

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.

kIERO commented on 2023-01-25 15:23 (UTC)

Thanks for the fix!

loathingkernel commented on 2023-01-25 11:55 (UTC) (edited on 2023-01-25 11:57 (UTC) by loathingkernel)

@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.

rfried commented on 2023-01-25 11:34 (UTC)

@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?

loathingkernel commented on 2023-01-25 09:15 (UTC) (edited on 2023-01-25 11:56 (UTC) by loathingkernel)

@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.

ssorgatem commented on 2023-01-25 09:13 (UTC)

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