| Summary: | Potential issues caused by non-namespaced RPM provides and libraries | |||
|---|---|---|---|---|
| Product: | Red Hat Software Collections | Reporter: | Honza Horak <hhorak> | |
| Component: | perl | Assignee: | perl-maint-list | |
| Status: | CLOSED ERRATA | QA Contact: | Martin Kyral <mkyral> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | rh-perl520 | CC: | mkyral, ppisar | |
| Target Milestone: | --- | |||
| Target Release: | 2.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | rh-perl520-2.0-6.el6,rh-perl520-mod_perl-2.0.8-5.20150122svn1653807.el6,rh-perl520-perl-5.20.1-321.el6,rh-perl520-perl-Algorithm-Diff-1.1903-1.el6,rh-perl520-perl-App-a2p-1.007-5.el6,rh-perl520-perl-App-find2perl-1.003-5.el6 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
Enabling software collections repository in the package
manager.
Consequence:
Installing a Red Hat Enterprise Linux package could
install some of the software collections packages instead
of the true package from the Red Hat Enterprise package
repository. As a result, the code provided by the Red Hat
Enterprise Linux package might not work.
Fix:
All dependency symbols specific to the Perl software
collections exported on the RPM level were mangled in
order not to conflict with Red Hat Enterprise Linux
packages.
Result:
Enabling software collection repository is safe and does
not have influence on resolving dependencies among
Red Hat Enterprise Linux packages.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1057175 (view as bug list) | Environment: | ||
| Last Closed: | 2015-06-04 09:33:52 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1042837, 1057175 | |||
|
Description
Honza Horak
2013-12-13 14:56:06 UTC
These should be filtered by %perl_default_filter macro which uses %{perl_vendorarch} which comes from rpm system macros.
Please, apply for libraries like libperl.so, libruby.so, libv8.so prefix, as documented in http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-Prefixing_the_Library_Major_soname_with_the_Collection_Name.html. mod_perl solved by rebuild. libperl.so must stay because we would create incompatibility between RHSCL-1.0 and RHSCL-1.1. The infix can be added in RHSCL-2.0. This will be addressed in rh-perl520. The collection-specific prefix or infix will be rh-perl520. This is current state for rh-perl520 on RHEL-6:
# repoquery --repoid=perl520add --requires rh-perl520\* | sort -u | grep -v -e 'rh-perl520'
db4-devel
gdbm-devel
glibc-devel
groff
libbz2.so.1()(64bit)
libcrypto.so.10()(64bit)
libcrypt.so.1(GLIBC_2.2.5)(64bit)
libcrypt.so.1()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdb-4.7.so()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libdl.so.2()(64bit)
libgdbm.so.2()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libm.so.6()(64bit)
libmysqlclient.so.16(libmysqlclient_16)(64bit)
libmysqlclient.so.16()(64bit)
libnsl.so.1()(64bit)
libpq.so.5()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
libpthread.so.0()(64bit)
libresolv.so.2()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
librt.so.1()(64bit)
libsqlite3.so.0()(64bit)
libssl.so.10()(64bit)
libutil.so.1()(64bit)
libz.so.1(ZLIB_1.2.0.2)(64bit)
libz.so.1(ZLIB_1.2.0.8)(64bit)
libz.so.1(ZLIB_1.2.2.3)(64bit)
libz.so.1(ZLIB_1.2.2)(64bit)
libz.so.1()(64bit)
postgresql-server
rtld(GNU_HASH)
/sbin/ldconfig
scl-utils
scl-utils-build
systemtap-sdt-devel
/usr/bin/perl
# repoquery --repoid=perl520add --provides rh-perl520\* | sort -u | grep -v -e 'rh-perl520'
So the only suspicious dependency is a run-require on /usr/bin/perl. This comes from collection dependency generators (/usr/lib/rpm/perl.{prov,req}.stack). Unfortunately one needs to use system perl for generating the dependencies because the generators are run out of collection environment and of course they have to be available for building the collection perl interpreter itself.
Bugfix verified. There are no non-namespaced provides: # rpm -qa rh-perl520* --provides | sort -u | grep -v -e 'rh-perl520' # and the list of non-namespaced requires looks sane: # rpm -qa rh-perl520* --requires | sort -u | grep -v -e 'rh-perl520' gdbm-devel glibc-devel groff httpd24-httpd-devel(x86-64) httpd24-httpd-mmn = 20120211x8664 libaprutil-1.so.0()(64bit) libapr-1.so.0()(64bit) libbz2.so.1()(64bit) libcrypto.so.10()(64bit) libcrypt.so.1(GLIBC_2.2.5)(64bit) libcrypt.so.1()(64bit) libc.so.6(GLIBC_2.11)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6()(64bit) libdb-devel libdb-5.3.so()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libdl.so.2()(64bit) libexpat.so.1()(64bit) libgdbm_compat.so.4()(64bit) libgdbm.so.4()(64bit) liblber-2.4.so.2()(64bit) libldap_r-2.4.so.2()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) libmysqlclient.so.18(libmysqlclient_18)(64bit) libmysqlclient.so.18()(64bit) libnsl.so.1()(64bit) libpq.so.5()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libpthread.so.0()(64bit) libresolv.so.2()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) librt.so.1()(64bit) libsqlite3.so.0()(64bit) libssl.so.10()(64bit) libutil.so.1()(64bit) libz.so.1(ZLIB_1.2.0.2)(64bit) libz.so.1(ZLIB_1.2.0.8)(64bit) libz.so.1(ZLIB_1.2.2.3)(64bit) libz.so.1(ZLIB_1.2.2)(64bit) libz.so.1()(64bit) postgresql-server rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) /sbin/ldconfig scl-utils systemtap-sdt-devel /usr/bin/perl # Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-1065.html |