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

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.

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.

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

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,

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.

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.

> 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

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.

FEDORA-EPEL-2019-2c04a2ffb5 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c04a2ffb5

FEDORA-EPEL-2019-2c04a2ffb5 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c04a2ffb5

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.

> 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)

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

You can add karma to the update above to speedup its going from testing to stable (else wait up to 14 days).

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

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.