On Sun, 2005-03-20 at 00:56 -1000, Warren Togami wrote:
> # 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
Your use of backwards/forward compatible here is reversed from what
we use in the GTK+ project. Backwards compatibility means that the
library is compatible with older applications. Forwards compatibility
means that the applications compiled with newer libraries work with
older applications... something we only guarantee within a stable
series.
> # 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.
I think it's inappropriate to add this sort of thing to particular spec
files ... while it may solve some user problems, the accumulation of
this type of cruft is going to make the spec files unmaintainable.
Doing it in the redhat-config-rpm would make more sense ... but I'm not
really sure there is anything special about glib. Other than libc, the
number of libraries we ship that add new symbol versions for newly
added symbols is close to zero. GLib-2.6 perhaps is a little more of any
issue than many because the expansion of g_return_if_fail() changed
to include a new symbol, but RPM cannot correctly find the required
version of *any* library that introduces new symbols without
symbol versioning.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part
