https://bugzilla.redhat.com/show_bug.cgi?id=2228155 --- Comment #23 from Steve Cossette <farchord@xxxxxxxxx> --- I did find someone that is willing to sponsor you yesterday after I posted here. We'll get back to this once the review is done. There's still one issue left: dante-devel.x86_64: E: invalid-soname /usr/lib64/libdsocks.so libdsocks.so Fedora's documentation does have some use cases for this: https://fedoraproject.org/wiki/Common_Rpmlint_issues#invalid-soname Namely: >The handling of this error depends on ld.so's load path (the "linker path") and whether it refers to a private or public library. >The linker path is %{_libdir} + any path listed in /etc/ld.so.conf or in a file in /etc/ld.so.conf.d. >Public libraries are libs expected to be used by other packages, Other libraries e. g., plugins and functionality internal to the package are private. >We have four cases: >The library is public. Inform upstream about the issue and propose that they add or fix versioning, possibly by sending a patch. Don't apply the patch until it's merged upstream to avoid upgrade problems. >The library is stored outside the linker path. In this case the error can be ignored. >The library is private and stored in a directory included in the linker path. If possible, move the library to another directory outside the linker path. This might require patching build scripts. >The library is private, stored in a directory included in the linker path and can't be moved. Here, the library must have a name unlikely to clash with other libraries. Consider filtering the Provides: to make sure the private library isn't visible. >The standard way to move a private library is to create a new directory under %{_libdir} e. g., /usr/lib/myapp. Don't list it in /etc/ld.so.conf files! Instead, use a rpath to let the application locate the library. I feel like moving the file to it's own directory would be the prefered solution. >Upstream states that the missing versioning is deliberate as this library is used for preloading and the name is hardcoded in scripts (such as socksify). They say it is not meant for direct linking so the name is not versioned. The problem is more that, imagine there's an existing package called "PackageX" that comes with it's own "libdsocks.so". Unless that other package has that file in a subdirectory outside of the linker path, both packages would clash. That's the problem that library versioning usually tries to solve. Ultimately, how you resolve this problem is up to you. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2228155 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202228155%23c23 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
