Red Hat Bugzilla – Bug 453855
Review Request: globus-openssl-module - Globus Toolkit - Globus OpenSSL Module Wrapper
Last modified: 2009-05-12 20:25:08-openssl-module package contains:
Globus OpenSSL Module Wrapper
BuildRequires: gpt
BuildRequires: libtool
BuildRequires: globus-gsi-proxy-ssl-devel >= 1
BuildRequires: globus-common-devel >= 3
BuildRequires: globus-gsi-openssl-error-devel >= 0
BuildRequires: globus-openssl-devel >= 1
BuildRequires: globus-core-devel >= 4
New version based on the globus toolkit 4.2.1 release:
SRPM:
SPEC:
All applied patches submitted upstream:
Initialization of openssl module should call SSL_library_init:
Fix a typo in the metadata file:
Typo patch has been accepted upstream:
openssl module should call SSL_library_init:
- Package builds in rawhide:
! BuildRequires: globus-openssl-devel >= 1 on the main package and
Requires: globus-openssl-devel >= 1 on the devel package seem unnecessary. They are not harmful though (they are picked up by other deps).
? Actually could you explain me those other Requires' in the devel package? The header file globus_openssl.h does not #include anything other than "globus_common.h". Where do the other dependencies come from? I bet it is a magical globus thingy, but I'd like to learn the mechanism.
The BuildRequires on globus-openssl-devel makes sense since there are direct dependencies on openssl in the sources (globus-openssl is the GPT glue package for openssl):
#include "openssl/crypto.h"
#include "openssl/err.h"
#include "openssl/ssl.h"
The requires in the devel package must not only satisfy the include dependencies in the installed headers but also the link dependencies. These can either be derived using GPT:
[ellert@ellert ~]$ globus-makefile-header globus_openssl_module -flavor=gcc32pthr | grep GLOBUS_PKG_LIBS
GLOBUS_PKG_LIBS = -lglobus_openssl -lglobus_openssl_error -lglobus_proxy_ssl -lglobus_common -ldl -L/usr/kerberos/lib -lssl -lcrypto -ldl -lz -lltdl
or using pkg-config:
[ellert@ellert ~]$ pkg-config --libs globus-openssl-module
-L/usr/kerberos/lib -lglobus_openssl -lglobus_proxy_ssl -lglobus_openssl_error -lglobus_common -lltdl -lssl -lcrypto -ldl -lz
The pkg-config file is generated from the GPT metadata, so the list should be the same (though the order might differ).
The Requires and BuildRequires in the spec file are automatically derived from the GPT source package description file pkgdata/pkg_data_src.gpt.in. This information is also used during the build to generate the GPT package installed GPT metadata file for the development package, which is the input for the generation of the pkg-config file. So the Requires in the devel package and what ends up as dependencies in the pkg-config file should be consistent.
The "magic globus thingy" is really only parsing and putting together the relevant part of the GPT source package description file which is XML. The perl script used is currently linked from the Packaging Draft page. It has been suggested to make the script part of globus-core (see the discussion page for the Packaging Draft).
Alright then. Thanks for the explanation. No further questions. This one is good to go:
--------------------------------------------------------
This package (globus-openssl-module) is APPROVED by oget
--------------------------------------------------------
Hold on, I said "no further questions" but I need to take a step back and ask another:
* The installed package gives the rpmlint:
$ rpmlint globus-openssl-module
globus-openssl-module.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libglobus_openssl.so.0.0.6 /lib64/libdl.so.2
globus-openssl-module.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libglobus_openssl.so.0.0.6 /lib64/libz.so.1
globus-openssl-module.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libglobus_openssl.so.0.0.6 /usr/lib64/libltdl.so.3
globus-openssl-module.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libglobus_openssl.so.0.0.6 /lib64/libpthread.so.0
Also, some of the other globus packages that we approved have these kind of warnings. Are these warnings given because the .pc files report more links than they actually need to? Or how can we fix these?
This is a different, but related, issue. This happens quite frequently for packages using pkg-config as well - so it is not a GPT specific issue.
This issue is documented here:
The above reference also suggests a solution for the problem. The solution involves a sed replacement in the libtool file. In the Globus case this is easily implemented, since there is a common libtool file in globus-core used by all packages. So the fix only needs to be applied in globus-core, and then all other packages will be OK once they are rebuilt.
I have applied the fix for globus-core and rebuilt the already approved packages. If you rebuild this package using the new globus-core this package will be OK too.
Yes, that fixed it. Thanks. I'm glad that was an easy fix.
---------------------------------------------------------------
This package (globus-openssl-module) is really APPROVED by oget
---------------------------------------------------------------
Do you need to rebuild everything against the new globus-core now? :-(
Thank you for the review. I'm happy it was easy too.
New Package CVS Request
=======================
Package Name: globus-openssl-module
Short Description: Globus Toolkit - Globus OpenSSL Module Wrapper
Owners: ellert
Branches: F-9 F-10 F-11 EL-4 EL-5
InitialCC:
cvs done.
globus-openssl-module-0.6-1.fc10 has been submitted as an update for Fedora 10.
globus-openssl-module-0.6-1.fc9 has been submitted as an update for Fedora 9.
globus-openssl-module-0.6-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
globus-openssl-module-0.6-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
globus-openssl-module-0.6-1.fc11 has been submitted as an update for Fedora 11.
globus-openssl-module-0.6-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.