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 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".
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
