#3 Split out wined3d to subpackages
Closed 4 months ago by frantisekz. Opened 6 months ago by frantisekz.
rpms/ frantisekz/wine dxvk_prep  into  master

file modified
+79 -7

@@ -40,7 +40,7 @@ 

  

  Name:           wine

  Version:        4.12.1

- Release:        2%{?dist}

+ Release:        3%{?dist}

  Summary:        A compatibility layer for windows applications

  

  License:        LGPLv2+

@@ -188,6 +188,16 @@ 

  

  # x86-32 parts

  %ifarch %{ix86} x86_64

+ # wined3d subpackaging

+ Requires:       wine-d3d9(x86-32) = %{version}-%{release}

+ Requires:       wine-d3d10(x86-32) = %{version}-%{release}

+ Requires:       wine-d3d11(x86-32) = %{version}-%{release}

+ Requires:       wine-dxgi(x86-32) = %{version}-%{release}

+ 

+ Recommends:     wine-wined3d-d3d9(x86-32) = %{version}-%{release}

+ Recommends:     wine-wined3d-d3d10(x86-32) = %{version}-%{release}

+ Recommends:     wine-wined3d-d3d11(x86-32) = %{version}-%{release}

+ Recommends:     wine-wined3d-dxgi(x86-32) = %{version}-%{release}

  %if 0%{?fedora} || 0%{?rhel} <= 6

  Requires:       wine-core(x86-32) = %{version}-%{release}

  Requires:       wine-capi(x86-32) = %{version}-%{release}

@@ -213,6 +223,16 @@ 

  

  # x86-64 parts

  %ifarch x86_64

+ # wined3d subpackaging

+ Requires:       wine-d3d9(x86-64) = %{version}-%{release}

+ Requires:       wine-d3d10(x86-64) = %{version}-%{release}

+ Requires:       wine-d3d11(x86-64) = %{version}-%{release}

+ Requires:       wine-dxgi(x86-64) = %{version}-%{release}

+ 

+ Recommends:     wine-wined3d-d3d9(x86-64) = %{version}-%{release}

+ Recommends:     wine-wined3d-d3d10(x86-64) = %{version}-%{release}

+ Recommends:     wine-wined3d-d3d11(x86-64) = %{version}-%{release}

+ Recommends:     wine-wined3d-dxgi(x86-64) = %{version}-%{release}

  Requires:       wine-core(x86-64) = %{version}-%{release}

  Requires:       wine-capi(x86-64) = %{version}-%{release}

  Requires:       wine-cms(x86-64) = %{version}-%{release}

@@ -668,6 +688,46 @@ 

  This package adds the opencl driver for wine.

  %endif

  

+ %package wined3d-dxgi

+ Summary:        DXGI implementation

"DXGI implementation for Wine" maybe?

+ Requires:       wine-core = %{version}-%{release}

+ 

+ Conflicts:      wine-dxvk-dxgi

+ Provides:       wine-dxgi%{?_isa} = %{version}-%{release}

+ 

+ %description wined3d-dxgi

+ DXGI implementation provided by wine.

+ 

+ %package wined3d-d3d9

+ Summary:        d3d9 implementation

+ Requires:       wine-dxgi%{?_isa} = %{version}-%{release}

+ 

+ Conflicts:      wine-d9vk

+ Provides:       wine-d3d9%{?_isa} = %{version}-%{release}

+ 

+ %description wined3d-d3d9

+ d3d9 implementation provided by wine.

+ 

+ %package wined3d-d3d10

+ Summary:        d3d10 implementation

+ Requires:       wine-dxgi%{?_isa} = %{version}-%{release}

+ 

+ Conflicts:      wine-dxvk

+ Provides:       wine-d3d10%{?_isa} = %{version}-%{release}

+ 

+ %description wined3d-d3d10

+ d3d10 implementation provided by wine.

+ 

+ %package wined3d-d3d11

+ Summary:        d3d11 implementation

+ Requires:       wine-dxgi%{?_isa} = %{version}-%{release}

+ 

+ Conflicts:      wine-dxvk

+ Provides:       wine-d3d11%{?_isa} = %{version}-%{release}

+ 

+ %description wined3d-d3d11

+ d3d11 implementation provided by wine.

+ 

  %prep

  %setup -q -n wine-%{version}

  %patch511 -p1 -b.cjk

@@ -1424,10 +1484,6 @@ 

  %{_libdir}/wine/ctapi32.dll.so

  %{_libdir}/wine/ctl3d32.%{winedll}

  %{_libdir}/wine/d2d1.%{winedll}

- %{_libdir}/wine/d3d10.%{winedll}

- %{_libdir}/wine/d3d10_1.%{winedll}

- %{_libdir}/wine/d3d10core.%{winedll}

- %{_libdir}/wine/d3d11.%{winedll}

  %{_libdir}/wine/d3d12.dll.so

  %{_libdir}/wine/d3dcompiler_*.%{winedll}

  %{_libdir}/wine/d3dim.%{winedll}

@@ -1476,7 +1532,6 @@ 

  %{_libdir}/wine/dwrite.dll.so

  %{_libdir}/wine/dx8vb.%{winedll}

  %{_libdir}/wine/dxdiagn.%{winedll}

- %{_libdir}/wine/dxgi.dll.so

  %if 0%{?wine_staging}

  %{_libdir}/wine/dxgkrnl.sys.so

  %{_libdir}/wine/dxgmms1.sys.so

@@ -1894,7 +1949,6 @@ 

  %{_libdir}/wine/sfc.%{winedll}

  %{_libdir}/wine/wineps.%{winedrv}

  %{_libdir}/wine/d3d8.%{winedll}

- %{_libdir}/wine/d3d9.%{winedll}

  %{_libdir}/wine/opengl32.dll.so

  %{_libdir}/wine/wined3d.dll.so

  %{_libdir}/wine/dnsapi.dll.so

@@ -2176,6 +2230,21 @@ 

  %files capi

  %{_libdir}/wine/capi2032.dll.so

  

+ # wined3d

+ %files wined3d-dxgi

+ %{_libdir}/wine/dxgi.dll.so

+ 

+ %files wined3d-d3d9

+ %{_libdir}/wine/d3d9.%{winedll}

+ 

+ %files wined3d-d3d10

+ %{_libdir}/wine/d3d10.%{winedll}

+ %{_libdir}/wine/d3d10_1.%{winedll}

+ %{_libdir}/wine/d3d10core.%{winedll}

+ 

+ %files wined3d-d3d11

+ %{_libdir}/wine/d3d11.%{winedll}

+ 

  %files devel

  %{_bindir}/function_grep.pl

  %{_bindir}/widl

@@ -2222,6 +2291,9 @@ 

  %endif

  

  %changelog

+ * Sun Jul 28 2019 Frantisek Zatloukal <fzatlouk@redhat.com> - 4.12.1-3

+ - Prepare for dxvk package installation - split out wined3d to subpackages

+ 

  * Sat Jul 27 2019 Fedora Release Engineering <releng@fedoraproject.org> - 4.12.1-2

  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  

This splits out wined3d files into subpackages, so users would be able to choose which d3d implementation they want (either wined3d or dxvk).

New package review request is coming soon for wine-dxvk, testing copr is available here:

https://copr.fedorainfracloud.org/coprs/frantisekz/wine-dxvk/

By default, users get wined3d libs (eg. after dnf install wine). To get dxvk implementation (replace wined3d), you can do:

dnf install wine wine-dxvk
# or, if you have wine installed already
dnf install wine-dxvk --allowerasing

Getting wined3d back is the same procedure as above, just installing wine-wined3d-d3d11 instead of wine-dxvk.

I hope I didn't overlook anything in the spec, I'll try to test how it behaves during wine updates tomorrow in another copr repo and I'll post results here.

How this works:
wine requires wine-d3d9, wine-d3d10...
wine-d3dx is going to be provided by two packages: wine-wined3d-d3dx (default because of recommends mechanism) and wine-dxvk (or wine-d9vk for d3d9)

Some testing before merging is welcome, I am planning to post on some Fedora MLs to get more testers.

wine-dxvk Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=1733798
wine-d9vk Review Request: Coming soon(tm)

"DXGI implementation for Wine" maybe?

Problems:

  1. Requires: wine = %{winever}

Wine releases bi-weekly and I update bi-weekly. I really don't want to have to add your package to my update list and do a release bump / rebuild every two weeks.

2.:
Provides: wine-d3d10%{?_isa} = %{winever}
Provides: wine-d3d11%{?_isa} = %{winever}
Conflicts: wine-wined3d-d3d10%{?_isa} = %{winever}
Conflicts: wine-wined3d-d3d11%{?_isa} = %{winever}

Same as above.

I would argue we should attempt to solve this with 'alternatives' instead. Both packages could then be installed at once and the "winner" would default to dxvk if installed. I'll split out the packages and setup alternatives on the wine side for the 4.13 update.

Let me be clear: I am not creating sub-packages.

What you need to do is add alternatives commands to your dxvk package and this will all be taken care of:
1. Rename your DLLs with a dxvk prefix.
Example:

mv %{buildroot}%{_libdir}/wine/dxgi.dll.so %{buildroot}%{_libdir}/wine/dxvk-dxgi.dll.so
touch %{buildroot}%{_libdir}/wine/dxgi.dll.so
  1. Add alternative commands to %posttrans
    Example:
%{_sbindir}/alternatives --install %{_libdir}/wine/dxgi.dll.so \
  wine-dxgi %{_libdir}/wine/dxvk-dxgi.dll.so 20
  1. Add alternative commands to %postun
%{_sbindir}/alternatives --remove wine-dxgi %{_libdir}/wine/dxvk-dxgi.dll.so

You can build the PE DLLs for D3D10/11 and ELF for dxgi.

Let me be clear: I am not creating sub-packages.
What you need to do is add alternatives commands to your dxvk package and this will all be taken care of:
1. Rename your DLLs with a dxvk prefix.
Example:
mv %{buildroot}%{_libdir}/wine/dxgi.dll.so %{buildroot}%{_libdir}/wine/dxvk-dxgi.dll.so
touch %{buildroot}%{_libdir}/wine/dxgi.dll.so

Add alternative commands to %posttrans
Example:

%{_sbindir}/alternatives --install %{_libdir}/wine/dxgi.dll.so \
wine-dxgi %{_libdir}/wine/dxvk-dxgi.dll.so 20

Add alternative commands to %postun

%{_sbindir}/alternatives --remove wine-dxgi %{_libdir}/wine/dxvk-dxgi.dll.so

You can build the PE DLLs for D3D10/11 and ELF for dxgi.

Hi! I have some problems with your last alternatives commit.

First of all, in the postinstall script i get this message (the same message from all alternative-managed dlls):

failed to link /usr/lib64/wine/dxgi.dll.so -> /etc/alternatives/wine-dxgi: /usr/lib64/wine/dxgi.dll.so exists and it is not a symlink

That happens because updates tries to create the symlink, but it already exists because you touched it first.

I dont know why that touch is needed, but for the already-present alternatives (wine/wineserver) you can see that the touched files are not installed:

%ghost %{_bindir}/wine
%ifnarch %{arm}
%ghost %{_bindir}/wine-preloader
%endif
%ghost %{_bindir}/wineserver

I think something similar should be done with dxgi, d3d9, d3d10, d3d10_1, d3d10core and d3d11.


The second problem happens when installing 32-bit and 64-bit versions of wine. I get this message from the postinstall script (the same message from all alternative-managed dlls):

the primary link for wine-dxgi must be /usr/lib64/wine/dxgi.dll.so

That happens because with wine-core-x86_64 you mark /usr/lib64/wine/dxgi.dll.so as an alternative-managed symlink with name wine-dxgi, but in wine-core.i686 you try to do the same to /usr/lib/wine/dxgi.dll.so, using the same alternative name.

I fixed bot issues (and did a little cleanup) in my personal copr with this commit (i changed the name to 64-bit alternatives)

I forgot to mark the old files as %ghost. The touch is needed so RPM sees a file to not package as a %ghost file. I'll update the alternatives to include the arch and correct the file list.

@frantisekz you would now use this:

%{_sbindir}/alternatives --install %{_libdir}/wine/dxgi.dll.so \
'wine-dxgi%{?_isa}' %{_libdir}/wine/dxvk-dxgi.dll.so 20

Thanks @mooninite !

One last thing, doesn't slave alternatives need to be differentiated as well? (links for them are also created in /etc/alternatives/)

You can build the PE DLLs for D3D10/11 and ELF for dxgi.

Hmm, the problem is, DXVK PE DLLs aren't picked up by wine (I've tested it on 4.12.1, will retest on 4.13 but I don't expect any changes here), it seems DXVK needs to be distributed as ELF in order to wine pick that up. I assume I wouldn't be able to use alternatives if files are named differently.

I'll try to think about more options how to solve this :/

Thanks.

Edit: Btw, if it was done in subpackages, I wouldn't expect you to bump also my package (even if it was ideal), but shouldn't upgrading wine without having bumped dxvk (worst case scenario) result in getting wined3d back?

Wine ships the D3D DLLs as PE:

$ rpm -ql wine-core | egrep "d3d(9|10|11)."
/usr/lib64/wine/d3d10.dll
/usr/lib64/wine/d3d11.dll
/usr/lib64/wine/d3d9.dll
/usr/lib/wine/d3d10.dll
/usr/lib/wine/d3d11.dll
/usr/lib/wine/d3d9.dll

It would be really strange if wine would not load the DXVK versions.

No, shipping sub-packages would not provide any sort of fallback. DNF would fail to upgrade due to the dxvk package requiring an older version of wine.

So, finally, wine-dxvk has been added to Rawhide (and only there, because it needs newer mingw than what is available in F30): https://src.fedoraproject.org/rpms/wine-dxvk

It is however a little hacky solution: it ships both PE .dll files and ELF .so files for all of the libraries. It is using the alternatives you have added to your wine for .dll files and dxgi.dll.so. This way, it works even with wine ignoring dxvk PE files because it is still able to load the .so files if they are present.

It would be really strange if wine would not load the DXVK versions.

Yeah, it is, but having dxvk's d3d11 set up as a provider of wine-d3d11(arch) results in:

module:import_dll Library d3d11.dll (which is needed by L"C:\\windows\\system32\\nvapi.dll") not found
# the file is there of course

Switching back to wine implementation fixes the issue. This is probably something I should ask wine devs about. I've created copr with wine-dxvk with pe dll files only, if you wanted to take a look: https://copr.fedorainfracloud.org/coprs/frantisekz/dxvk-pe/

No, shipping sub-packages would not provide any sort of fallback. DNF would fail to upgrade due to the dxvk package requiring an older version of wine.

Yeah, I've meant dnf update --best --allowerasing , sorry for not specifying that explicitly.

Anyway, huge thanks for adding alternatives support for dx libraries in wine package!!!

Pull-Request has been closed by frantisekz

4 months ago