What drives RPM Provides for shared libraries?

Toshio Kuratomi a.badger at gmail.com
Wed Dec 22 18:18:25 UTC 2010


On Wed, Dec 22, 2010 at 09:43:51AM -0500, Tom Lane wrote:
> Panu Matilainen <pmatilai at laiskiainen.org> writes:
> > One possibility is to keep the upstream created symlinks and add the 
> > necessary provides manually in the spec.
> 
> Right offhand that seems less magic than the ELF-hacking alternatives.
> However, how do I get the conditional "(64bit)" property on the Provides
> items?  I hope there's a better way than #ifarch'ing for all the known
> 64-bit arches ...

As another approach, giflib has this snippet so things can link against
libungif::

# Handling of libungif compatibility
MAJOR=`echo '%{version}' | sed -e 's/\([0-9]\+\)\..*/\1/'`
%{__cc} $RPM_OPT_FLAGS -shared -Wl,-soname,libungif.so.$MAJOR -Llib/.libs -lgif -o libungif.so.%{version}

%install
# Handling of libungif compatibility
install -p -m 755 libungif.so.%{version} $RPM_BUILD_ROOT%{_libdir}
ln -sf libungif.so.%{version} $RPM_BUILD_ROOT%{_libdir}/libungif.so.4
ln -sf libungif.so.4 $RPM_BUILD_ROOT%{_libdir}/libungif.so

It's very old so I don't know if it's still the best way to do things.

Another thought is that within the distro, patching software to stop using
the deprecated library name is what we want.  For Fedora, removing the
compatibility symlink, not providing an alternative, and rebuilding any
packages that use the older library name  may be the right way to go.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101222/b4cca0fe/attachment.bin 


More information about the devel mailing list