Bug 953499

And the very same problem is with requires.

Even if I change provides - in my case I done it as:
%if %{?scl:1}%{!?scl:0}
  # Do not check .so files in the libdir
  %global __provides_exclude_from ^(%{_libdir}/*.so.*)$
%endif
...
# When running in SCL add provides of libdir manually
%if %{?scl:1}%{!?scl:0}
%if "%{__isa_bits}" == 64
Provides %{?scl_prefix}libv8.so.3()(64bit)
Provides %{?scl_prefix}libv8preparser.so.3()(64bit)
%else
Provides %{?scl_prefix}libv8.so.3()
Provides %{?scl_prefix}libv8preparser.so.3()
%endif
%endif

Then the requires will be still the same. In my case (abbreviated):
# rpm -q --requires ruby193-v8
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libpthread.so.0()(64bit)  
libpthread.so.0(GLIBC_2.2.5)(64bit)  
libv8.so.3()(64bit)  
libv8preparser.so.3()(64bit)


But I want to have 
 ruby193-libv8.so.3()(64bit) 
 ruby193-libv8preparser.so.3()(64bit)
instead of orginal ones. But leaves other intact.

I would very welcome something like
%global _use_scl_libs libv8.so libv8preparser.so

And if such libraries are find in automatically generated requires or provides they would be prepend with scl prefix.

You are mixing the provides and requires in your description. If I understand it correctly, you are defining your provides with a prefix but requires are not prefixed. That actually sounds correct to me, at least from the rpm side of things. You might want to consider using %__requires_exclude_from as well.

Could you please post me rpm -q --provides to see if everything is ok on that front?

The v8 mentioned in #1 is here:
http://koji.katello.org/koji/buildinfo?buildID=4101

(In reply to Miroslav Suchý from comment #3)
> The v8 mentioned in #1 is here:
> http://koji.katello.org/koji/buildinfo?buildID=4101

So I did some testing on the package. On the first line I put a definition of scl macro:
%global scl ruby193

And the expected result after build:

ruby193-libv8.so.3()(64bit)
ruby193-libv8preparser.so.3()(64bit)
ruby193-v8 = 1:3.10.8-7.fc18
ruby193-v8(x86-64) = 1:3.10.8-7.fc18
scl-package(ruby193)

Perhaps we are missing something ...

I actually build it under rhel6.
There the provides are always:
 libv8.so.3()(64bit)
no matter if I define scl macro on first line or in meta package.

Ok so after some more discussion on IRC this has been limited only to RHEL6 builds. The root cause is that rpm in RHEL6 doesn't support __provides_exclude_from.

Switching the product and keeping the bug for the moment as a tracker. We will investigate our options further.

Filed a bug 1001674 to document the situation. This bug is deferred until there is a demand for this to be fixed.

*** Bug 996025 has been marked as a duplicate of this bug. ***

Removing the dependency on RHSCL 1.1 tracker. As I have indicated above, I am not going to implement this unless absolutely necessary for something super important. The amount of work on this too high considering the potential benefit.

Currently, we are using "infixes" in shared objects e.g. libv8OURCOLLECTION.so.3()(64bit). I guess it won't be easy to implement it in scl-utils. I would leave it for scl-utils2 if we find better general solution.

(In reply to Marcela Mašláňová from comment #11)
> Currently, we are using "infixes" in shared objects e.g.
> libv8OURCOLLECTION.so.3()(64bit).

This wouldn't work, since we need to keep the library name unchanged (unless all dependencies are patched), just adjusting the soname works better. This is what we actually use:

libv8.so.OURCOLLECTION-3()(64bit).

Also worth mentioning (and sorry for repeating myself), that solving RPM provides issue is only one of the two issues we face. The second issue is runtime linking -- if scl-utils would only change the provides, it wouldn't prevent applications to link against wrong libraries.

So I still believe that changing the soname by manual patching is much better solution than hacking scl-utils to fix provides and let the libraries fail during linking possibly.

I agree. It has to be patched manually.