https://bugzilla.redhat.com/show_bug.cgi?id=1377762 --- Comment #14 from Carl George <carl@george.computer> --- That's fine about the test suite, it's understandable to skip it if the build requirements to run it are missing. Try to enable it in the future once you can. I ran fedora-review on this now, and it has highlighted a few other issues. > [ ]: Package contains systemd file(s) if in need. Upstream has unit files for dhtnode and dhtcluster, please include them and their relevant config files (see my note about cmake below). > [ ]: Latest version is packaged. Upstream is chugging right along and has released 1.9.0. > opendht.x86_64: E: explicit-lib-dependency libargon2 RPM automatically adds dependencies for linked libraries it detects, so you should be able to just remove these: -Requires: msgpack -Requires: gnutls -Requires: libargon2 > opendht.x86_64: W: no-manual-page-for-binary dhtchat > opendht.x86_64: W: no-manual-page-for-binary dhtnode > opendht.x86_64: W: no-manual-page-for-binary dhtscanner Upstream has a man page for dhtnode, please include it (see my note about cmake below). There isn't man pages for the other two, don't worry about them. > opendht.src:15: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 15) Use one or the other. Most packagers stick with just spaces. > opendht.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libopendht.so.0.0.0 /lib64/librt.so.1 > opendht.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libopendht.so.0.0.0 /lib64/libdl.so.2 Try to fix these (see my note about cmake below). https://fedoraproject.org/wiki/Common_Rpmlint_issues#unused-direct-shlib-dependency Something else I noticed that I didn't before was your use of globs in %files. You can use globs, but try to be more explicit. Here's how I would do it. -%{_libdir}/*.so.* +%{_libdir}/libopendht.so.0* -%{_includedir}/* -%{_libdir}/*.so +%{_includedir}/opendht* +%{_libdir}/libopendht.so https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files Speaking of the libraries, I thought it was strange that the soname was 0.0.0. If you compile with autotools, you get libopendht.so.0.0.0. But if you compile with cmake, you get libopendht.so.1.8.2. This was reported upstream in the past, fixed, then regressed. https://github.com/savoirfairelinux/opendht/issues/75 https://github.com/savoirfairelinux/opendht/pull/95#issuecomment-481768325 I can't even get 1.9.0 to compile with autotools, so I suggest just switching to cmake. This will have some other benefits too, such as installing the systemd files and man pages. It also makes the unused-direct-shlib-dependency rpmlint warning go away. Here's the changes I would make. +BuildRequires: cmake (in the devel subpackage) +Requires: cmake-filesystem (in %build) -autoreconf --install --verbose -Wall -%configure --disable-static +%cmake -DOPENDHT_STATIC=OFF -DOPENDHT_SYSTEMD=ON . (in %install) -find $RPM_BUILD_ROOT -name '*.la' -delete (in %files) +%config %{_sysconfdir}/dhtnode.conf +%{_unitdir}/dhtnode.service +%{_mandir}/man1/dhtnode.1* (in %files devel) +%{_libdir}/cmake/opendht Last suggestion, have you considered splitting the files out further? It's fine as is, but it might be beneficial to end users to have a more minimal install of just the tool they want. I was thinking of separate packages for: - dhtchat (command) - dhtnode (command, systemd unit, systemd config, man page) - dhtscanner (command) - libopendht (library) - opendht-devel (devel files) I'm not familiar enough with this software to say which should depend on each other (or if this approach even makes sense), so feel free to disagree here. I just think in the interest of minimalism, another package should be able to require libopendht without pulling in CLI tools or systemd units. You could also put all the CLI tools in one subpackage, separate from the library, such as opendht-tools. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
