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. EXCEPT: 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 libglib-2.0.so.0(GLIB_2.31.0), 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. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature