Hello! On Wednesday 26 December 2012 19:35:31 Jeffrey Johnson wrote: >On Dec 22, 2012, at 8:27 AM, Joachim Langenbach <joac...@falaba.de> wrote: >> Hello, >> >> I'm trying to create a RPM, which produces three packages for a library. >> The first is the library without kde bindings, the second is the library >> with kde bindings and the third is the development package. I'm using the >> following file structure for installing: >> >> 1. library without kde installs into RPM_BUILD_ROOT (includes the header >> and other developing files) 2. library with kde installs into >> RPM_BUILD_ROOT/kde4 >> >> I choose this sepparation, because both libraries are building the >> libengsas.so file, with identical API, but different internal bindings. So >> applications, using libengsas, can link against one version of it and it >> is independent from the one, which the user has installed on the system. >> >> But I have not found a way to tell RPM in the "%files kde" that the >> directory /kde4/usr/lib must be installed at /usr/lib on the users >> machine, when installing the package. >> >> Is there a way, I can solve this problem? > >The usual way to handle different content on (presumably) identical >path on the file system is to use alternatives outside of rpm. > >Using alternatives invokes a helper in %post that creates whatever >symlink on the shared/conflicting path to a private store.
I've used this solution for my executable and the ld-config file solution for my library. > >There's another approach since you are packaging libraries with >different content but similar symbols. Put each library into a different >directory, and then configure ld.so with search paths, or (somewhat >more elegant) build with rpath to find the library that was linked >into an application. > >One can also use --relocate /usr/lib=/usr/lib/kde to change the >file paths when installing (but you will need to re-add --relocate >every time you upgrade, the values are not persistently stored). > >You can use pkgconfig to encapsulate flags needed to find the various >library path arguments. > >I'm not sure any of the above has much to do with RPM itself. Its impossible >to have different content on a common path, well duh! > >hth > >73 de Jeff The RPM is building now. Many thanks! Regards, Joachim Langenbach
signature.asc
Description: This is a digitally signed message part.