> 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".
I can honestly say that I think there might be a better way than what you
are doing, but since I don't package libraries like that normally, I don't
know. I would recommend exploring some of the compat packages to see if
they have a better idea.
As far as the hacky way you are talking about, I do have some past
experience that could possibly help. When re-packaging CA's ArcServe for
distribution on our old platform we had issues with the requires generated
by the standard dependancy generator. The following code is how it was
dealt with.
# Set dependency information:
%define _use_internal_dependency_generator 0
%define arc_requires %{_tmppath}/arc-requires
%define __find_requires %{arc_requires}
%prep
# Fix dependency issues
cat << EOF > %{arc_requires}
/usr/lib/rpm/find-requires | grep -vE \
"libc.so.6.1|libcompat.1.so|libframe.1.so|libiiapi.1.so|libinterp.1.so|
libq.1.so|libstdc\+\+-libc6.1-1.so.2"
#/usr/lib/rpm/find-requires | grep -vE \
"libc.so.6.1|libcompat.1.so|libframe.1.so|libiiapi.1.so|libinterp.1.so|
libq.1.so"
EOF
chmod 755 %{arc_requires}
I can't explain how this method was found, I was showed when I started here
by the person that figured it out.
hope that it helps you find your way.
-greg
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
