Bug 1412305 - Remove elfutils library provides in DTS rpms
Summary: Remove elfutils library provides in DTS rpms
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: elfutils
Version: DTS 6.1 RHEL 7
Hardware: Unspecified
OS: Unspecified
Target Milestone: alpha
: 6.1
Assignee: Mark Wielaard
QA Contact: Martin Cermak
Depends On: 1392589
TreeView+ depends on / blocked
Reported: 2017-01-11 17:23 UTC by Mark Wielaard
Modified: 2020-06-11 13:11 UTC (History)
16 users (show)

Fixed In Version: devtoolset-6-elfutils-0.168-3
Doc Type: Bug Fix
Doc Text:
The devtoolset-6-elfutils-libs package provided the same shared library object names as the base RHEL elfutils-libs package. Consequently, if a package required one of the provided elfutils libraries (libelf, libdw, or libasm), devtoolset-6-elfutils-libs was installed instead of the base RHEL elfutils-libs package. With this update, devtoolset-6-elfutils-libs no longer provides the same library names as the system elfutils-libs package. As a result, when a package needs an elfutils-libs library, the system elfutils-libs package is correctly installed.
Clone Of: 1392589
Last Closed: 2017-04-26 09:47:27 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1149 0 normal SHIPPED_LIVE devtoolset-6-elfutils bug fix and enhancement update 2017-04-26 13:39:26 UTC

Comment 2 Mark Wielaard 2017-01-13 14:37:29 UTC
So it can be done on RHEL too, but differently:

But note that this disables some of the internal rpm marking like file coloring which might break multilib installs. I think it is fine in this case because only the main elfutils package contains executables and that sub-package isn't multilib. All other packages have their executable files in separate directories and so should still be parallel installable.

So when the fix is installed we need to double check
a) no devtoolset-6-elfutils* subpackage Provides libelf, libdw.so or libasm.so.
b) all elfutils sub-packages we ship multilib (x86_64 and i686 variants) can still be installed in parallel.

Filter being tested right now:

# The lib[64]/elfutils directory contains the private ebl backend
# libraries. They must not be exposed as global provides. We don't
# need to filter the requires since they are only loaded with dlopen.
%if 0%{?fedora} >= 15
%global __provides_exclude ^libebl_.*\\.so.*$
# scl _libdir isn't actually the normal libdir, so don't provide any
# libraries installed there.
%{?scl:%filter_provides_in %{_libdir}/.*\.so$}
%filter_provides_in %{_libdir}/elfutils/libebl_.*\.so$

Comment 4 Mark Wielaard 2017-01-16 10:46:26 UTC
After discussion with Martin we decided to try a different approach.

We don't really trust the old (RHEL6) rpm to do the right thing with filter_provides_in. And the multilib conflicts because of the missing file coloring are scary.

So instead of filtering out the provides we are now changing the SONAME version for libelf, libdw and libasm to "dts.1". This should work fine for the internal usage and signals that these packages can not be used to resolve a normal elfutils library provides.

Note that since we do provide overrides (static linker scripts) for libelf.so, libdw.so and libasm.so in the -devel subpackages everything still works (and doesn't generate a requires) for anything building against these libraries (because they'll really get the static code).

Comment 5 Martin Cermak 2017-02-23 15:41:38 UTC
On all the testing boxes I'm getting output similar to the following:

 7.4 Server x86_64 # eu-readelf --dynamic --notes /opt/rh/devtoolset-6/root/usr/lib64/lib{dw,asm,elf}-0.168.so | egrep '^/opt|SONAME'
  SONAME            Library soname: [libdw.so.dts.1]
  SONAME            Library soname: [libasm.so.dts.1]
  SONAME            Library soname: [libelf.so.dts.1]
 7.4 Server x86_64 #

Comment 6 Martin Cermak 2017-02-23 15:48:57 UTC
Verified with devtoolset-6-elfutils-0.168-3.el[67].

Comment 8 errata-xmlrpc 2017-04-26 09:47:27 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.