I think I have mentioned this on the list before, but without getting
any answers, so I'll try again:
I'm building RPMs for some of the software products offered by my
employer. There are several "library" and application products that
depend on each other the usual way. In other words, there may be an rpm,
let's call it application-1.0, which contains applications linked with a
certain library DSO, say liblibrary.so.1. Now, liblibrary.so.1 would
normally be installed as /usr/lib/liblibrary.so.1 by the package
library-1.0 - and autoreqprov would create the right dependencies
between application-1.0 and library-1.0.
So far so good. But for certain technical and political reasons, I'm not
allowed to do things that way; I actually have to include
liblibrary.so.1 in the application-1.0 package(s), even though it really
belongs to product "library". Furthermore, there may also be a different
application, let's say another-program-2.1, that uses and must have its
own version of liblibrary.so.1. And I would still like to keep
liblibrary-1.0, as it may contain its own "standalone" utilities etc. I
therefore get 3 different packages that want to own liblibrary.so.1.
So what do I do? Obviously, I first of all need to make sure that the
different RPMs won't try to install the same file. For instance, I might
package the .so file as follows:
liblibrary-1.0: /usr/lib/liblibrary.so.1
application-1.0: /usr/lib/application-1.0/liblibrary.so.1
another-program-2.1: /usr/lib/another-program-2.1/liblibrary.so.1
The executables in "application" and "another-program" would of course
be set up to look for DSOs under /usr/lib/application-1.0 and
/usr/lib/another-program-2.1, respectively. This can also be handled
quite well by rpm - although I'll probably want to switch off
autoreqprov when building application-1.0 and another-program-2.1.
I'm not entirely happy with this setup, however. I still want to keep
things as "correct" as possible, and also think it is cleaner to keep
"application" itself separate from the external libs it uses, so I
really want to put /usr/lib/application-1.0/liblibrary.so.1 *in a
separate rpm*, so that I get e.g.
% rpm -ql application
/usr/bin/application
% rpm -ql application-libs
/usr/lib/application-1.0/liblibrary.so.1
Furthermore, I'd like to look at this non-standard library installation
as merely an alternative to using the base package the proper way, i.e.
give the user to choose between "library" and "application-libs" when
resolving dependencies in "application". The question is how to set up
the rpm dependencies. The ones added via "autoreqprov" works if
"application" and "library" only are involved, of course, but if I as
soon as "another-program" comes into the picture, I'm in trouble; rpm
will think that "application-libs" can be used to satisfy its
dependencies, but it can't really, since the program(s) in
"another-program" won't look for DSOs on the directory where
"application-libs" installs them.
So is there a way I can get rpm to handle this scenario? I mean, without
hardcoding information on applications whithin the "library" package.
Can I somehow say that "application-libs" provides liblibrary.so.1, but
only for "application-1.0"? Or can I say that "application-1.0" requires
"library-1.0" OR "application-libs"? Any other ideas?
- Toralf
