[packman] obs-studio erroneously provides libvulkan.so.1

Dave Plater davejplater at gmail.com
Wed Nov 9 07:39:31 CET 2022


On 11/9/22, Dave Plater <davejplater at gmail.com> wrote:
> On 11/8/22, Giacomo Comes <comes at naic.edu> wrote:
>> On Tue, Nov 08, 2022 at 08:58:17PM +0100, Hans-Peter Jansen wrote:
>>> Hi,
>>> looking for advise on how to deal with an unpleasant situation:
>>> Look at the handbrake TW build right now:have choice for
>>> libvulkan.so.1()(64bit) needed by libavutil56_70: libvulkan1 obs-studio,
>>> have choice for libvulkan.so.1()(64bit) needed by libavfilter7_110:
>>> libvulkan1 obs-studio
>>> and indeed from the obs-studio build:
>>> [  542s] -- Installing:
>>> /home/abuild/rpmbuild/BUILDROOT/obs-studio-28.1.1-0.x86_64/usr/lib64/obs-plugins/libvulkan.so.1
>>> [  556s] Processing files: obs-studio-28.1.1-0.x86_64[  557s] Provides:
>>> application() application(com.obsproject.Studio.desktop)
>>> libEGL.so()(64bit) libGLESv2.so()(64bit) libcef.so()(64bit)
>>> libobs-frontend-api.so.0()(64bit) libobs-opengl.so.1()(64bit)
>>> libobs-scripting.so.1()(64bit) libobs.so.0()(64bit)
>>> libobsglad.so.1()(64bit) libvk_swiftshader.so()(64bit)
>>> libvulkan.so.1()(64bit) metainfo()
>>> metainfo(com.obsproject.Studio.appdata.xml) obs-studio = 28.1.1-0
>>> obs-studio(x86-64) = 28.1.1-0
>>> Due to the automatic dependency processing, obs-studio now provides a
>>> libvulkan.so.1 plugin, which in turn provides libvulkan.so.1()(64bit) on
>>> the package, which is kind of silly of course. Sure, this could be
>>> solved
>>> by within prjconf with:
>>> Prefer: libvulkan1
>>> but I would rather like to remove this provides from obs-studio build
>>> specifically. Any idea, how to achieve that?
>>
>> Add in the spec file something like:
>> %define __provides_exclude ^(libvulcan\\.so.*|libEGL\\.so.*)$
>>
>> Check the documantation here:
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
>>
>> Regards,
>> Giacomo
>>
>>> Cheers,Pete--Life without chameleons is possible, but pointless.
>>>
>>>

 Another workaround is #!BuildIgnore: the wrong package in the specfile

Regards
Dave



More information about the Packman mailing list