Re: How to handle requires/provides with DSOs are in non-standardlocations?

[Toralf Lund <toralf procaptura com>]

> In regard to: How to handle requires/provides with DSOs are in non-standard...:
>
>  
>
> > A-libs provides libb.so.1, but only for the use by package A.
> >
> > Is this possible? Or is there a better way to handle the dependencies?
> > Obviously, I could drop all references to libs, and have dependency on
> > (virtual) packages instead, but this doesn't seem very neat... Any other
> > suggestions?
> >    
>
> I can think of no elegant solution to this problem.  Is this an
> application and library that you control?  Could you give the library
> an SONAME that no other application is likely to ever use?
>  
Yes and no.

One of the reasons why I may want to package libs as outlined above, is 
to minimise the risk of breaking the system because of unanticipated 
SONAME conflicts with other people's libs (this situation is less likely 
to occur if I limit the number of DSOs installed on /usr/lib.) Another 
is that I sometimes need to package customised or upgraded versions of 
libs that may already be present on /usr/lib - and it is not practical 
to upgrade the original library package. This is actually the situation 
I'm in right now. (It's not ideal, but can be hard to avoid in pracsis.) 
In this case I can easily change the SO names of the libs, the question 
is if I want to. It would be nice to retain the possibility of using the 
"public" version, and switch to that if and when the update is installed 
globally.

> I'm not sure exactly how the Red Hat `glibc' package is built, such that it
> defines a number of "Version definitions", but perhaps you could play
> games with your library so that it does the same.  See
>
> 	rpm -q --provides glibc
>
> and
>
> 	objdump -x /lib/libc.so.6
>
> for an example of some of the version definitions glibc has.  If you could
> get your library so that it *only* provides
>
> 	libb.so.1(APPLICATION_A_PRIVATE)
>
> (and not just `libb.so.1') or something like that, other packages that
> require a library with a SONAME of libb.so.1 would never think that your
> library satisfies that requirement.
>  
Yes. Maybe I could use a mechanism like that somehow. Although if I want 
to be able to choose between a global version of a lib and my private 
one, I guess I would need to require libb.so.1(APPLICATION_A_PRIVATE) 
*or* libb.so.1

Does anyone else know how exactly the library name mechanisms in glibc work?

> All of these depend on you being able to manipulate how the library is
> built.
>
> Tim
>  
- Toralf