Todd Rinaldo wrote:
> 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.
Normally some packages would depend on libjpeg.so.10 and some
packages depend on libjpeg.so.11 ?
Your packaging (build) requires can depend on jpeg-7 and jpeg-8, but
that is slightly different.
> 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)
For libraries, normally libjpeg.so would only be required by
"development" packages, for building. The "deployment" packages would
rather look for a specific version, as seen with ldd(1) and friends.
Things like Ports, that use source packages, normally doesn't bother
with two types of subpackages. But then again they usually rebuild
all depending ports on library version bumps, so there is only one.
> 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
> 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".
Your packaging "works" when doing something like packaging kde and
kde4 or large things like that.
For simple libraries, it is probably overkill. But see http://
nixos.org/nix for the extreme version...
Received on Mon Apr 26 12:22:51 2010