Am Do., 15. Feb. 2024 um 17:22 Uhr schrieb Petr Pisar <ppisar@xxxxxxxxxx>: > > 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 <ppisar@xxxxxxxxxx>: > > > > > > 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) Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch builds for fc39 and el9 yields libmupdf.so.23.10()(64bit) in both cases. I could try and stuff %__elf_provides into the spec for a koji scratch debug run ... Michael -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
