# Require Binary Compatible glib
%define glib_ver %(pkg-config --modversion glib-2.0 | cut -d. -f 1,2)
Requires: glib2 >= %{glib_ver}I added this to gaim.spec a while ago because users were installing rawhide gaim compiled against glib2-2.6.x on FC3, which has glib2-2.4.x. gaim was then crashing because:
1) applications compiled against a newer glib are not backwards ABI compatible. AFAIK glib is supposed to be only forward ABI compatible. [1]
2) glib does not use verisoned so names
3) so rpm auto-dep cannot enforce compatible glib ABI version
# Require Binary Compatible glib
%define glib_ver %(pkg-config --modversion glib-2.0 | cut -d. -f 1,2)
Requires: glib2 >= %{glib_ver}What the above spec chunk does is read the pkgconfig file contained in glib2-devel, and cut out the the major and minor version. That version is used to make an artificial RPM dependency on glib versions that are supposed to be ABI compatible with the package.
While it is totally unsupported for a user to install packages from newer distributions on older distributions, they do it anyway. It causes upset feelings, confusion, and a waste of time with bogus reports. But there may be a simple and robust way to automate and avoid this problem.
Proposal:
RPM (via redhat-rpm-config?) should implicitly add something like the above spec blob in order to enforce glib ABI dep, but *only* if the binary payload actually links to glib.
Thoughts? Is this feasible to implement in a clean way? Will this fail in any corner cases?
[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149190
This is unrelated to the above RFC, but if I understand this correctly, glib2-2.6 g_stat() changed in such a way that breaks ABI forward compat. Somebody that knows glib better can verify or explain this? Or maybe it was already fixed upstream.
