Bug 723575
Summary: | Review Request: libpki - Easy-to-use PKI library | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Patrick Monnerat <patrick> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | notting, package-review |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-11-28 12:36:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Patrick Monnerat
2011-07-20 15:43:01 UTC
Not a full review: > %global with_doc 1 %bcond_without doc 1 is more flexible and mighty as a default. With it you could simply toggle the %with_doc macro when building, e.g. rpmbuild --without doc ... > # Remove unneeded files. > > rm -rf "${RPM_BUILD_ROOT}%{_datadir}/libpki" Something like this asks for an explanation in a spec file comment. It is obvious that "rm -rf" removes an entire tree, but the _why_ isn't answered. What files are in there and why are they unneeded? > #------------------------------------------------------------------------------- > %post > #------------------------------------------------------------------------------- > > /sbin/ldconfig > > > #------------------------------------------------------------------------------- > %postun > #------------------------------------------------------------------------------- > > /sbin/ldconfig Caution! Here you create shell scripts that contain your long '#----...' lines, because there is no way yet to decide which comment is part of the script or just the spec file. Take a look at e.g. the rpm -qp --scripts libpki-*rpm output of the built packages. If you really want to execute just ldconfig, prefer running it directly with an automatic dependency on its path instead of /bin/sh: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig > %{_bindir}/pki-cert > %{_bindir}/pki-crl > %{_bindir}/pki-derenc > %{_bindir}/pki-query > %{_bindir}/pki-request > %{_bindir}/pki-siginfo > %{_bindir}/pki-tool > %{_bindir}/pki-xpair > %{_bindir}/url-tool Very generic names that bear a high risk of causing conflicts with other/future packages, especially if these tools are shipped within a library package. Just the '-' in 'pki-' and 'url-' currently creates an own namespace. However, the 'pki' and 'url' prefix is in use already: $ repoquery --whatprovides /usr/bin/pki\* pki-console-0:9.0.2-1.fc15.noarch procps-0:3.2.8-19.20110302git.fc15.x86_64 pki-setup-0:9.0.9-1.fc15.noarch pki-setup-0:9.0.7-1.fc15.noarch procps-0:3.2.8-21.20110302git.fc15.x86_64 librapi-0:0.15.1-1.fc15.i686 librapi-0:0.15.1-1.fc15.x86_64 pki-silent-0:9.0.7-1.fc15.noarch pki-console-0:9.0.3-1.fc15.noarch pki-silent-0:9.0.9-1.fc15.noarch $ yum list pki-\*|wc -l 21 $ repoquery --whatprovides /usr/bin/url\* gridsite-clients-0:1.7.15-4.fc15.x86_64 python-urlgrabber-0:3.9.1-10.fc15.noarch urlwatch-0:1.12-1.fc15.noarch urlview-0:0.9-8.fc15.x86_64 gridsite-clients-0:1.7.9-2.fc15.x86_64 Even if this library's tools plan to occupy the 'pki-' namespace for executables like this (and not the 'libpki-' namespace), it would be better to move these files into a libpki-tools or libpki-utils package, so the tools remain optional whereas the library package might be dragged in as a dependency of something. $ libpki-config --cflags -I/usr/include/libxml2 -DLINUX The libpki-devel package is missing a dependency on libxml2-devel as pki.h and several other headers include libxml headers, but the pkgconfig file explicitly depends on libxml-2.0.pc. Further, libpki.pc is broken (which also explains why the automatic .pc file dep has not been added by rpmbuild): $ cat /usr/lib64/pkgconfig/libpki.pc |grep libdir libdir=/usr/lib The deeper look at the pkgconfig problem: $ pkg-config --cflags libpki Package openssl-0.9.8 was not found in the pkg-config search path. Perhaps you should add the directory containing `openssl-0.9.8.pc' to the PKG_CONFIG_PATH environment variable Package 'openssl-0.9.8', required by 'libpki', not found $ cat /usr/lib64/pkgconfig/libpki.pc|grep ^Req Requires: libxml-2.0 openssl-0.9.8 $ ls /usr/lib64/pkgconfig/openssl.pc /usr/lib64/pkgconfig/openssl.pc $ rpm -q openssl-devel openssl-devel-1.0.0d-1.fc15.x86_64 $ pkg-config --print-requires libpki $ That's why the pkgconfig dep generation fails. Thanks for the partial review. Here are the new links: SPEC: http://monnerat.fedorapeople.org/libpki.spec SRPMS: http://monnerat.fedorapeople.org/libpki-0.6.5-2.fc14.src.rpm Last changelog: * Fri Jul 22 2011 Patrick Monnerat <pm> 0.6.5-2 - Patch "pkgconfig" to fix pkg-config configuration file. - Sub-package "tools" for binary utilities. - libxml2-devel dependence added to devel sub-package. - "rpmbuild ... --without doc" is now recognized. rpmlint unchanged, except tools related messages issued by new tools sub-package instead of -devel. Thanks for the %bcond_without trick: I did not know it. %post and %postun scriptlets: WONTFIX. I agree with you it should be done this way, but this is an RPM problem. I tried "-p", but it does not work unless the next lines are empty until the next '%xxx' paragraph. I also tried %macros, but they are not substituted inside a scriptlet. Since the current solution works perfectly (though requiring /bin/sh which is always already present), I keep it unchanged to preserve my RPM comments: those improve a lot the readbility. RPM should provide a dummy "%endOfScript" paragraph or a comment escape scriptlet option to resolve this problem, but this is not the topic of this review request :-/ There are still upstream problems with this package (i.e.: soname): I'm in contact with the upstream project maintainer about them. Thanks again Michael for your work on it. Too many problems (memory leaks) with this library: resigning. Will live with old version of ocspd not using it. |