[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

How to handle requires/provides with DSOs are in non-standard locations?



Another question related to the setup I described in another post earlier today:

Let's say I have a package 'A' containing an application 'a' and a lib 'b' that I don't want to share with everyone, and therefore install on, say, /usr/lib/A, i.e. I have

/usr/bin/a
/usr/lib/A/libb.so.1

Or similar. 'a' is linked with -rpath '/usr/lib/A' -lb, so it will load /usr/lib/A/libb.so.1 on startup (and not, if it exists, /usr/lib/libb.so.1), while the runtime linker won't find it for other programs that may be linked with (a different) libb. This setup has one problem already: Package A will by default provide libb.so.1 even though it's not available for general use.

Question 1: What's the best way to avoid that.

Now, I actually want a more complex setup. I want to have

Package A:
/usr/bin/a

Package A-libs:
/usr/lib/A/libb.so.1

The question is how I describe the dependency between A and A-libs. If I assume they are alone in the world, the default Autoreqprov setup is fine, but like I mentioned above, I really don't want anyone else to see that libb.so.1. Essentially, I want to say

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?

- Toralf




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]