V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a): > 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: > Does running a dependency generator for ELF files on that file report the expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There should be a ".../elfdeps --provides" command for generating provides. Take that command and pass the library file as a possitional argument. An example:
/usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301 libacl.so.1(ACL_1.0)(64bit) libacl.so.1(ACL_1.1)(64bit) libacl.so.1(ACL_1.1)(64bit) libacl.so.1(ACL_1.2)(64bit) libacl.so.1(ACL_1.2)(64bit) libacl.so.1()(64bit) -- Petr
signature.asc
Description: PGP signature
-- _______________________________________________ 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
