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

[Toralf Lund <toralf procaptura com>]

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