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? 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. All of these depend on you being able to manipulate how the library is built. Tim -- Tim Mooney mooney@xxxxxxxxxxxxxxxxxxxxxxxxx Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
