Symbol versioning

Thinking about adding a symbol reminds me of a common complaint I have
about GNOME packages, which I just worked out how to fix for one of my
own projects.

When you have a stable library API (and soname), and you *add* a symbol,
that's all very well. Programs linked against the new version of the
library, *if* they use the new symbol, cannot then be run against an
older version of the library. Everyone knows that, and it's fine.


The system packaging (rpm, dpkg) doesn't know it. So when I pick a few
newer packages from Fedora 17 to run on my F16 system (because I need
some bug fixes for libvirt, for example), the RPM dependencies are
incorrect. A F17 package might need a newer glib than the one that's
present in F16, but its RPM dependencies don't *say* that because the
soname is the same, so I just get a broken program that doesn't run.

The fix for this is to use symbol versioning. When we add a symbol, it
gets marked with the new version (e.g. g_key_file_get_type@@GLIB_2.31.0)
and then any package which *uses* that symbol will automatically pick up
a dependency on, and we won't get broken
package dependencies.

Is there a reason we don't use symbol versioning on GNOME packages?
There are toolchains which don't support it, obviously, but it's not so
hard to make it conditional. It works on Solaris and GNU toolchains.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]