Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar <ppi...@redhat.com>:
>
> V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > Hi there
> >
> > I recently switched mupdf to shared libraries. During test builds on
> > COPR for EPEL I noticed a strange difference to fedora builds which I
> > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > difference is in the automatic provides for the -libs sub package:
> >
> > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> >
> > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > mupdf-libs(x86-64) = 1.23.10-2.fc39
> >
> > And, of course, packages built against mupdf-devel automatically
> > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> >
> > I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> >
> > Both packages have the same file contents including the lib, the
> > SONAME is `libmupdf.so.23.10`.
> >
> Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about
> rpmbuild not to generate provides and requires for a SONAME if the libary is
> not installed into a standard library path.
It's in /usr/lib64/ in both cases (x86_64, checked with
rpmdev-extract). spec part is:
```
%files libs
%license COPYING
%{_libdir}/%{libname}.so.%{soname}
```
Michael
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
