https://bugzilla.redhat.com/show_bug.cgi?id=994474 --- Comment #8 from Michael Schwendt <bugs.michael@xxxxxxx> --- That's not what "private library" means. It's not only about the path within the Python modules dir. "Private" refers to a shared lib that is specific/local to your package (and software), with no public API/ABI for external programs to use, and regardless of where it's stored. Private non-versioned library names with no "lib" prefix are no real problem, since they bear almost no risk of causing an RPM dependency conflict. They mostly "pollute" the RPM/repository metadata, since they are useless because no other package should depend on them. qr_encode.so()(64bit) It's very unlikely that any other package will ever depend on a "qr_encode.so()(64bit)" library name, and it's similary unlikely that any other shared library will use exactly that library name and no version either. However, even for a lib name like that, one could construct a packaging scenario, where another program also builds and uses a shared library "something.so", storing it in a sub-package, resulting in a library name dependency between base package and sub-package. If any other package provided the same "something.so" thing, that could cause the dependency resolver to assume that either package provides the same required thing. It's worse for lib names that bear a higher risk of conflicting with system libs in run-time linker's search path. Private plug-in libs outside run-time linker's search path, for example, using lib names "libfoo.so", perhaps even a versioned "libfoo.so.0" name. Even if the private lib were a compatible copy of a system lib (bundled and not dropped yet), it could not be used to satisfy the dependency at run-time, if it's not stored in run-time linker's search path. That's not a theoretical problem anymore. Cases like that have been encountered in the package collection before. > it's not clear to me which private library you mean I took that literally and didn't understand it as a question what a private library is. The link posted by Christopher explains a bit: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering > As far as I understood qr_encode.so is an internal library > that should not be advertised as being provided by the package. > However, it does not do that in my opinion: That's what it means. ;-) The package _does_ contain automatic Provides/Requires for the shared lib, possibly depending on how/where you've built the package. The .fc20 dist tag in your test-build indicates you've built it for Fedora 20 development (Rawhide), where things may have changed. I'm not up-to-date on whether rpmbuild for F20 has been enhanced to ignore libs in private paths. For a Fedora 19 build, you could observe it: $ rpmlint -i python-qrencode-1.01-1.fc19.x86_64.rpm python-qrencode-debuginfo-1.01-1.fc19.x86_64.rpm python-qrencode.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/qr_encode.so qr_encode.so()(64bit) A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator. python-qrencode.x86_64: W: no-documentation 2 packages and 0 specfiles checked; 0 errors, 2 warnings. > And it's definitely not requiring it: That's true also for F19 and older, but that is because being a Python module lib, there is nothing inside your package that is linked with that lib. ;) That makes the automatic Provides even more useless, but it's not a big issue. $ rpm -qp --provides python-qrencode-1.01-1.fc19.x86_64.rpm |grep -v ^py qr_encode.so()(64bit) -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=10VhFH9RUB&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review