Package Details: dxvk-winelib-git 1.5.r3.ga265af74-2

Git Clone URL: https://aur.archlinux.org/dxvk-wine-git.git (read-only, click to copy)
Package Base: dxvk-wine-git
Description: A Vulkan-based compatibility layer for Direct3D 9/10/11 which allows running 3D applications on Linux using Wine. Winelib version
Upstream URL: https://github.com/doitsujin/dxvk
Licenses: zlib/libpng
Conflicts: d9vk-bin, d9vk-mingw-git, d9vk-winelib-git, dxvk-bin, dxvk-git, dxvk-mingw-git, dxvk-win32-git, dxvk-win64-git, dxvk-wine32-git, dxvk-wine64-git
Provides: d9vk, dxvk, dxvk=1.5.r3.ga265af74
Submitter: ssorgatem
Maintainer: ssorgatem
Last Packager: ssorgatem
Votes: 8
Popularity: 0.144082
First Submitted: 2018-07-22 16:53
Last Updated: 2019-12-17 22:16

Pinned Comments

ssorgatem commented on 2018-07-22 17:00

These packages use a winelib build of DXVK instead of a Windows build. This means they are built as a wine library rather than a Windows DLL. Therefore, they do not need a crosscompiler to be built.

They can replace the dxvk-mingw-git and dxvk-bin packages. Be sure to re-run the setup script if switching over from those.

To install DXVK on a WINEPREFIX (with the variable properly set):

setup_dxvk install

In order to uninstall DXVK from a wineprefix:

setup_dxvk uninstall

Latest Comments

1 2 3 4 5 Next › Last »

loathingkernel commented on 2019-12-18 11:36

If they should be able to coexist for the time being, they must not conflict

For the casual user it is irrelevant, if someone wants to, they can edit the PKGBUILD. It was a way of explaining why the transition is not a renaming process.

and there are indeed valid use cases for it in the AUR: package renames and merges.

The documentation talks about renames only, not merges. Using replaces for merges or that merges constitute renames is your own interpretation.

If the resolution makes no sense because it is based on false assumptions

Going by the word of the documentation is not a false assumption.

wuestengecko commented on 2019-12-18 11:18

we suggest through the conflicts array

conflicts=() is not a suggestion, but an enforcement - which is exactly my point. If they should be able to coexist for the time being, they must not conflict. Otherwise, only one of them can be installed at a time.

the Arch Wiki explicitly states that when uploading to the AUR, use provides and conflicts instead of replaces

I dare say that I do understand what replaces=() means, and there are indeed valid use cases for it in the AUR: package renames and merges. As the packages won't be merged right now, they don't replace, which we agree on.

let's stop polluting the comments section of a package, about an issue that got resolved between that package maintainers in two comments, because you disagree with what they agreed on, while being the maintainer of neither.

If the resolution makes no sense because it is based on false assumptions, then I see it as my duty to bring this to a maintainer's attention. Again: Right now, the packages must not conflict with each other.

loathingkernel commented on 2019-12-18 10:59

And the last commit in the d9vk repo is from 2 days ago

Exactly. It is too soon to act on it. The projects probably won't need to be split again, but let the dust settle first.

You're kind of contradicting yourself here

I am really not, and I don't know why such a simple concept is not understood. We want users to transition from d9vk to dxvk, users update their systems at different rates, ergo we suggest through the conflicts array that they should remove d9vk. It could be done with replaces, but the Arch Wiki explicitly states that when uploading to the AUR, use provides and conflicts instead of replaces https://wiki.archlinux.org/index.php/PKGBUILD#replaces. Also from the AUR submission guidelines that you referenced,

conflicts, on the other hand, is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.

Now, let's stop polluting the comments section of a package, about an issue that got resolved between that package maintainers in two comments, because you disagree with what they agreed on, while being the maintainer of neither.

wuestengecko commented on 2019-12-18 09:25

The d9vk packages still pull from a different source (repository) than the dxvk packages.

A repository which is abandoned with the merge of #1275. dxvk-mingw-git already provides d3d9.dll too (I assume the same is true for this build). And the last commit in the d9vk repo is from 2 days ago, just when aforementioned PR was merged. On the contrary, the dxvk upstream already saw new commits to the d3d9 tree just today.

d9vk could even be omitted from the conflicts array if the user wanted to have them alongside, it is a mere convenience to ease transitioning.

You're kind of contradicting yourself here - if the packages aren't to be merged already, then there is nothing to transition to. And then they shouldn't conflicts=() with each other either.

loathingkernel commented on 2019-12-18 02:28

The d9vk packages still pull from a different source (repository) than the dxvk packages. They are not building the dxvk source without d3d10 and d3d11. I will file deletion requests at some point in the next few months after the whole merging process has finalized and no further commits have happened in the d9vk repo.

wuestengecko commented on 2019-12-18 01:30

With the upstream projects merged, the packages should be merged too. If someone were to package dxvk now, they wouldn't arbitrarily split off the DX9 part - well, I certainly wouldn't. Arch usually does not split packages unless it's a big waste of space, and arguably that isn't the case here.

loathingkernel commented on 2019-12-17 23:46

@ssorgatem: Could it be that the AUR helper is messing up in this case? I have not tried it with an AUR helper, but here makepkg on proton-native is finding dxvk>=1.5 correctly.

@wuestengecko: I disagree with you. It is not a merge of the packages. It is a merge of the projects. The packages can still coexist in the system just fine as they are installed in separate folders. In essence one package doesn't replace the other, the dxvk packages don't provide /usr/share/d9vk/{x32,x64}/d3d9.dll, ergo they are not a direct replacement nor they conflict. d9vk could even be omitted from the conflicts array if the user wanted to have them alongside, it is a mere convenience to ease transitioning.

wuestengecko commented on 2019-12-17 23:03

@loathingkernel The AUR submission guidelines say:

Do not use replaces in an AUR PKGBUILD unless the package is to be renamed, for example when Ethereal became Wireshark.

A merge is basically renaming it into an already existing package, so replaces=('d9vk-winelib-git') is absolutely correct in this case.

ssorgatem commented on 2019-12-17 22:22

@loathingkernel it should be fixed now. But for some reason the proton-native packages don't seem to pick that up...? am I doing something wrong?

When I try to install either of them through pikaur, it complains about not finding dxvk in the AUR (?)

loathingkernel commented on 2019-12-17 19:58

The arch wiki advises against using replaces for the AUR.

From the arch wiki: If providing an alternate version of an already existing package or uploading to the AUR, use the conflicts and provides arrays, which are only evaluated when actually installing the conflicting package.

Also can you add provides=("dxvk=$pkgver") so other packages can require any packages that provide dxvk above a certain version?