Hello,
Toshio Kuratomi wrote:
> The not quite working portion is the virtual Provides. I think I'm
> running squarely into the issues exposed here:
>
> Should I try something like:
> %ifarch x86_64
> Provides: libungif.so.4()((64bit)
> %else
> Provides: libungif.so.4
> %endif
>
> or is that too much of a hack?
| Provides: libungif.so.4
...
| ln -sf libgif.so.%{version}
| ${RPM_BUILD_ROOT}%{_libdir}/libungif.so.%{version}
| ln -sf libungif.so.%{version} ${RPM_BUILD_ROOT}%{_libdir}/libungif.so.4
| ln -sf libungif.so.4 ${RPM_BUILD_ROOT}%{_libdir}/libungif.so
| ln -sf libgif.a ${RPM_BUILD_ROOT}%{_libdir}/libungif.a
This is quite an ugly hack IMHO: libgif.so and libungif.so should have a
different SONAME and not be just symlinks to the same library.
Otherwise when I intentionally link a program with -lungif, it will
actually require libgif.so.4 and it will break on any system which
has real libungif and no libgif. (Yes, this means that all applications
that really want to link to libgif will have to be modified if they
currently expect libungif.)
Providing a real library (which can be empty and just require
libgif.so.4) also solves the provides: (64bit) problems.
Mirek
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
