Bug 1745104

Summary: spirv-tools conflicts with vulkan from 7.7
Product: [Fedora] Fedora EPEL Reporter: Pablo Greco <pablo>
Component: spirv-toolsAssignee: Dave Airlie <airlied>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: epel7CC: airlied, ajax, bryan.dobson, dmitry, flaash, fritz, fschwarz, imcneal, mugasahat, orion, pasik, peter, scx.mail, tru, w.hoelzl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spirv-tools-2019.1-4.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-03 00:34:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Pablo Greco 2019-08-23 15:35:26 UTC
Description of problem:
spirv-tools provides /usr/lib64/libSPIRV-Tools-opt.so and /usr/lib64/libSPIRV-Tools.so which are now part of vulkan

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1.enable epel
2.yum install vulkan
3.yum install spirv-tools

Actual results:
(actually from updating vulkan with spirv-tools already installed, but same symptom)
Transaction check error:
  file /usr/lib64/libSPIRV-Tools-opt.so from install of vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package spirv-tools-libs-2019.1-1.el7.x86_64
  file /usr/lib64/libSPIRV-Tools.so from install of vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package spirv-tools-libs-2019.1-1.el7.x86_64



Expected results:
Both packages installed

Additional info:

Comment 1 Dmitry Butskoy 2019-08-27 18:09:40 UTC
Looks like design issue... :(

New Fedora's vulkan (or vulkan-validation-layers) package requires:
> libSPIRV-Tools-opt.so
> libSPIRV-Tools.so
both provided by spirv-tools-libs in Fedora.

New RHEL-7.7's vulkan requires these libraries too, but just deside to bundle it... And provides it to the system as well...

Probably prepare spirv-tools in EPEL7 just to add missing libraries (at least libSPIRV-Tools-shared.so is required by vkd3d, required by wine).

Comment 2 Peter Ajamian 2019-09-09 02:03:05 UTC
Stupid decision by Red Hat to bundle just the two libs instead of providing spirv-tools.  That leaves EPEL in the uneviable position of providing half of a package to make up the difference.  I would say the best of a number of bad choices is to just remove the two files from the EPEL spirv-tools and have spirv-tools require vulkan.

It's a sucky solution but probably the best under the circumstances.

Note that I would like to see this happen sooner rather than later because at the moment I am stuck cherry-picking just to get CentOS 7.7 with wine.

Comment 3 Peter Ajamian 2019-09-09 02:07:27 UTC
Maybe a slightly better approach would be to move the missing files to a sub-package (spirv-tools-extra-libs or something) and then have spirv-tools require that files (instead of the package) that way it would be usable with or without vulkan because eitehr vulkan or the sub-package would make up the difference.

Comment 4 Dmitry Butskoy 2019-09-09 17:18:41 UTC
> Stupid decision by Red Hat to bundle just the two libs instead of providing spirv-tools.

Probably the reason maybe spirv-tools-libs is a some kind of a new "barely stable" library, and nobody consider it as a stable one. At least, there are no soname versions (ie. ".so.NUM") in the binary files yet...

Unfortunately, it looks very unlikely that this issue will be fixed by RH for EPEL users. Probably at RHEL-7.8 time (if some customer will report it by their channels, not volunteer by BZ).

Fortunately, the only problem dependency in EPEL7 is "libvkd3d --> libSPIRV-Tools-shared.so".
If libvkd3d never matches vulkan libraries in some common executable, then it should be possible to rebuild libvkd3d with the bundled libSPIRV-Tools-shared.so (as vulkan now does, but surely not provide it for the whole system).

Another solution is to provide a truncated version of spirv-tools-libs for EPEL7, which must match the bundled ones in vulkan and must follow all the correspond changes in vulkan. It looks possible, since the person who made the problem vulkan change is the primary maintainer of spirv-tools. But he is silent (vacation?)

Comment 5 imcneal 2019-09-10 17:14:47 UTC
I have a customer who is experiencing this issue in a production env as well. Commenting for visibility


"Transaction check error:

  file /usr/lib64/libSPIRV-Tools-opt.so conflicts between attempted installs of spirv-tools-libs-2019.1-1.el7.x86_64 and vulkan-1.1.97.0-1.el7.x86_64

  file /usr/lib64/libSPIRV-Tools.so conflicts between attempted installs of spirv-tools-libs-2019.1-1.el7.x86_64 and vulkan-1.1.97.0-1.el7.x86_64

 

Error Summary"


Thanks,

Comment 6 Dave Airlie 2019-09-20 20:16:13 UTC
I'll try and look into it over the next couple of weeks. (I've got a lot more higher priority stuff)

Vulkan package spitting up for RHEL7 is unlikely to happen (it happened in Fedora and RHEL8). It's more likely EPEL will have to build a spirv-tools-extra or something that fits in with the packaged version from RHEL vulkan.

Comment 7 Peter Ajamian 2019-09-24 02:59:00 UTC
I agree not very likely for RHEL to fix the problem they created here, but it might be worth posting a bug to it anyways just on the odd chance that it's possible.  Certainly the "correct" way to fix it would be for RHEL to build sperv-tools-libs and take the libs out of vulkan, if they do that it would make everyone's life easier.

Comment 8 Tomasz Tomasik 2019-09-24 06:01:18 UTC
> Maybe a slightly better approach would be to move the missing files to a sub-package (spirv-tools-extra-libs or something) and then have spirv-tools require that files (instead of the package) that way it would be usable with or without vulkan because eitehr vulkan or the sub-package would make up the difference.

I am not sure if this is a good idea. If you choose to update the system, then it will update vulkan and vulkan-filesystem if they are already installed. Otherwise, it will probably install vulkan and vulkan-filesystem anyway (EL7 doesn't support weak dependencies, so we can't _recommend_ spirv-tools-extra-libs), although it should be possible to install spirv-tools-extra-libs if you really want to. However, if you do that, then you will be unable to install or update vulkan. So, in this case we return to the starting point.
Of course, you can always use yum shell to remove spirv-tools-extra-libs and install vulkan, but this solution will not please everyone.

I think the best we can do is to remove these two libs from spirv-tools-libs and require them.
We could also require vulkan%{?_isa} >= 1.1.97.0-1. However, if Red Hat f*cks up this package again (e.g. move spirv libs to the optional subpackage or just separated package), we will have to make some changes again.

Anyway, here is a temporary solution:
https://copr.fedorainfracloud.org/coprs/scx/spirv-tools/

All you have to do is just:
# yum copr enable scx/spirv-tools
and then:
# yum update

Comment 9 bryan.dobson 2019-09-25 19:27:08 UTC
How is this not a higher priority? This is becoming an increasingly big issue in installing new servers and updating others. I am currently excluding packages from updates in order to make certain functions work.

Comment 10 Fedora Update System 2019-09-28 23:23:19 UTC
FEDORA-EPEL-2019-2c04a2ffb5 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c04a2ffb5

Comment 11 Fedora Update System 2019-09-29 00:13:19 UTC
FEDORA-EPEL-2019-2c04a2ffb5 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c04a2ffb5

Comment 12 Pablo Greco 2019-09-29 12:11:24 UTC
Dave, shouldn't require be for vulkan >= 1.1.97.0 ? Otherwise you could end up in a state with half of spirv-tools.
Also it could be inside a %if 0%{?rhel} == 7, since all the other fixes are fedora compatible.

Comment 13 Tomasz Tomasik 2019-09-29 13:00:37 UTC
> Dave, shouldn't require be for vulkan >= 1.1.97.0 ? Otherwise you could end up in a state with half of spirv-tools.

This shouldn't be a problem because auto-generated requires will explicitly refer to libSPIRV-Tools-opt.so()(64bit) and libSPIRV-Tools.so()(64bit).

> $ rpm -qp --requires spirv-tools-libs-2019.1-4.el7.x86_64.rpm | grep libSPIRV-Tools
> libSPIRV-Tools-opt.so()(64bit)
> libSPIRV-Tools.so()(64bit)

Comment 14 Fedora Update System 2019-09-30 02:20:05 UTC
spirv-tools-2019.1-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c04a2ffb5

Comment 15 Dmitry Butskoy 2019-10-01 18:33:01 UTC
You can add karma to the update above to speedup its going from testing to stable (else wait up to 14 days).

Comment 16 Hatwib 2019-10-02 20:59:59 UTC
Try adding lines below in yum config file /etc/yum.conf:

    exactarch=1
    exactarchlist=*  #For Red Hat Enterprise Linux 7:

Then run yum commands:

    # yum clean all
    # yum update
    # rpm -Uvh --replacefiles spirv-tools-*.rpm
    # rpm -Uvh --replacefiles vulkan-*.rpm
    # rpm -Uvh --replacefiles wine-*.rpm

Comment 17 Fedora Update System 2019-10-03 00:34:19 UTC
spirv-tools-2019.1-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.