I've repeatedly been told and seen written in other threads that there is no
reason I should need to alter dependencies for provides/requires for a
generated RPM. I thought I'd give an example of my situation and perhaps I'm
missing something fundamental that someone can correct me on.
Note that this is an arbitrary example to show my issues authoring rpms
correctly. libjpeg is only an example here and could be switched out with foo
and my questions would be the same.
Situation: I have an rpm that needs to depend on libjpeg version 8. The OS this
will run on still comes with libjpeg 7. It would break too many other packages
that depend on libjpeg 7 if I were to upgrade the libjpeg that comes with the
OS in place.
My overall strategy: Create an rpm for a shared libjpeg version 8 and install
it to prefix=/opt/foo. We'll call the rpm foo-libjpeg8. Then take my dependant
software and compile it with relevant rpaths so it will find the correct
libjpeg.so in /opt/foo/lib/. It is important that this new rpm not advertise
that it provides libjpeg.so since this will either conflict with what the OS
provides and/or confuse anyone trying to install a package that depends on
libjpeg.so, assuming it'll be present in /usr/lib/libjpeg.so (mine will be in
/opt/foo/lib/libjpeg.so)
My RPM strategy:
1. provide a SOURCE3:
#!/bin/sh
/usr/lib/rpm/rpm-find-provides | grep -v 'libjpeg'
2. In the spec:
%define __find_provides %{SOURCE3}
3. In the dependent spec, I would need to filter out that it requires
libjpeg.so (similar to above but with requires) and instead explicitly:
BuildRequires: foo-libjpeg8
Requires: foo-libjpeg8
I realize rpm-find-requires was snipped from rpm5. I'm looking to an
alternative to my strategy here and just used it for ease of explanation.
I apologize if this information is already documented somewhere. Nothing I've
read so far clearly addresses the issue further than "Don't do it or you'll
break x and y and z".
Thanks,
Todd______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
