In regard to: How to handle requires/provides with DSOs are in non-standard...:Yes and no.
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?
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.
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.1I'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.
Does anyone else know how exactly the library name mechanisms in glibc work?
- ToralfAll of these depend on you being able to manipulate how the library is built.
Tim
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
