[Pkg-xfce-devel] Library symbols

Lionel Le Folgoc mrpouit at gmail.com
Sun May 9 11:03:41 UTC 2010


Hi there,

I started locally to add symbol files for some Xfce libraries. Having
symbols is nowadays being a "good citizen", and can avoid creating
backports, because a program will only depend on the library version
matching the symbols it uses.

So, I played a bit with desktop/branches/experimental by adding a symbol
file to libxfce4util, and rebuilt everything in there to see possible
improvements. Here is a quick summary (debdiff format):

* xfconf_4.7.2-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.3.99.2),+}
* libxfce4ui-1-0_4.7.2-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.3.99.2),+}
* libexo-1-0_0.5.2-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.3.99.2),+}
* exo-utils_0.5.2-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.3.99.2),+}
* xfce4-settings_4.7.1-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.6.0),+}
* libthunarx-2-0_1.1.0-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.3.99.2),+}
* thunar_1.1.0-1_amd64.deb: libxfce4util4 (>= [-4.7.0),-] {+4.3.99.2),+}

(this is probably the best example since libxfce4util is very stable,
only 4 symbols have been added for Xfce 4.6.0 [0 for 4.8.0], and only
xfce4-settings is using them.)

Also, since our upstream is rather knowledgeable about libraries, etc. I
think we can use symbol files for almost all Xfce libraries without
worrying too much[0].

For a new upstream release, when a new symbol has been added, but the
symbols file not updated, dpkg-gensymbols should display a warning (when
DPKG_GENSYMBOLS_CHECK_LEVEL=4, an error), and show a diff of the
symbols. Then, we only have to check that it is really supposed to be
exported, and update the symbols file consequently. Moreover, we don't
maintain low-level libraries, so there shouldn't be any arch-dep
specific symbol to deal with. Thus, I think the maintenance burden isn't
too big.

I tried to classify existing libs:
1) "very stable" libraries that should be ok: libxfce4util, libxfconf.
2) libraries that will have a soname bump for 4.8: libexo,
libxfce4panel, libthunarx.
3) new libraries: libxfce4ui, libgarcon, libtumbler.
4) deprecated ones: libxfce4menu, libxfcegui4, libthunar-vfs.

However, I'm not very confident for libxfce4ui, since it ships a private
lib (libxfce4kbd-private-2.so.0), and I'm not sure upstream intends this
one to be stable… Similarly, xfce4-panel 4.8 breaks the abi, and as
we're likely not going to split libxfce4panel in a separate package,
we'll have to put xfce4-panel (>= 4.7.0) in shlibs, which will limit the
benefits of symbol file.

Except these two corner cases, I think for 1 and 3 it's fine to add
symbols. For 2, unless upstream is going to bump the soname again every
morning, it should be fine too. And let's say we don't care about 4
since they will disappear…

Voila, this is what I found so far. I don't think this is a priority for
squeeze though, so I intend to add little-by-little symbols to
desktop/branches/experimental only, unless someone disagrees (e.g. if
the maintenance burden seems too huge).

Thoughts, ideas, something I forgot?

Cheers,
Lionel

[0] I checked several libs on mole/seedsymbols, and all libraries seem
to export only public symbols, except libxfcegui4 which is a bit of a
mess
(<http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libxfcegui4-4_i386>),
with some exported symbols that shouldn't be here afaik:
pango_get_context at Base, xinerama*@Base, get*Window at Base, etc.

-- 
Lionel Le Folgoc
E61E 116D 4BA1 3936 0A33  F61D 65D9 A66E 10E2 969A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20100509/77300513/attachment.pgp>


More information about the Pkg-xfce-devel mailing list