https://bugzilla.redhat.com/show_bug.cgi?id=866265
--- Comment #25 from Michael Schwendt <bugs.michael(a)gmx.net> ---
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