https://bugzilla.redhat.com/show_bug.cgi?id=866265 --- Comment #25 from Michael Schwendt <bugs.michael@xxxxxxx> --- > opentrep-python.x86_64: W: devel-file-in-non-devel-package > /usr/lib64/python2.7/site-packages/libpyopentrep/libpyopentrep.so > > If you have any idea as how to remove that warning, it is welcome! It's a limitation of the fedora-review tool, which apparently doesn't recognize Python's module path as a valid location for .so files. https://fedorahosted.org/FedoraReview/ - filing an RFE might lead to something. > $ rpmls opentrep-data-0.6.1-1.fc20.noarch.rpm > -rw-r--r-- /usr/share/opentrep/data/por/README.md > -rw-r--r-- /usr/share/opentrep/data/por/ori_por_public.csv It doesn't require the base package yet for proper directory ownership: $ rpm -qpR opentrep-data-0.6.1-1.fc20.noarch.rpm |grep -v ^rpm $ If it shall be possible for the -data subpackage to be installed independently, you may include the directories in it, too. Currently, the dependency is backwards, i.e. the base package requires the -data package. > $ grep lib64 rpms-unpacked/opentrep-devel-0.6.1-1.fc20.x86_64.rpm/usr/bin/opentrep-config > #libdir=/usr/lib64 It would still cause a conflict, because of that line. Other conflicts found in /usr/share/opentrep/CMake files: /usr/share is for arch-independent data, but several of the CMake files refer to /usr/lib64. A wrong Python path has been spotted in them, too: $ grep python/open * opentrep-config.cmake:set (OPENTREP_LIBRARY_DIRS "/usr/lib64:/usr/lib64/python/opentrep") opentrep-library-depends-debug.cmake: IMPORTED_LOCATION_DEBUG "/usr/lib64/python/opentrep/libpyopentrep.so.0.6.1" opentrep-library-depends-debug.cmake:list(APPEND _IMPORT_CHECK_FILES_FOR_pyopentreplib "/usr/lib64/python/opentrep/libpyopentrep.so.0.6.1" ) > Then, the following now works: > $ /usr/lib64/python2.7/site-packages/libpyopentrep/pyopentrep /usr/share/man/man1/pyopentrep.1.gz $ pyopentrep bash: pyopentrep: command not found... I still think it's a bad idea to include the manual page in section 1 without making available the pyopentrep command in $PATH. Since the -python subpkg is arch-specific and not multilib'ed it would be possible to symlink /usr/bin/pyopentrep to the script in Python module path. (cf. comment 22) > $ pkg-config --variable=docdir opentrep > /usr/share/doc/opentrep-0.6.1 Invalid for Fedora >= 20 unversioned docdirs. The opentrep-config script also contains this path, albeit unused in the script. > /usr/share/aclocal/opentrep.m4 One place that mentions Boost as requirement. Some of the header files want Boost headers, too, but the -devel package does not depend on any Boost -devel packages yet. Should the pkgconfig file depend on Boost, too? All are issues that sometimes are (re)introduced into packages also some time after review - any suggestions on how to proceed? -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review