Tricky question about libxfconf, xfconfd and soname
Brian J. Tarricone
bjt23 at cornell.edu
Fri Nov 7 12:06:27 CET 2008
Corsac and I chatted about this on IRC, so no need to reply. The
You can only have one xfconfd process running at once anyway (per user),
so having xfconfd in its own package is the way to go, and each
libxfconf-x-y package should depend on that single xfconfd package.
All versions of libxfconf released so far can talk to the newest
version of xfconfd, so there's no versioning issue.
If I ever break compatibility with the xfconf *dbus* interface, then
it's a problem, but there are ways to avoid doing that.
On Fri, 7 Nov 2008 11:37:56 +0100 Yves-Alexis Perez wrote:
> Ok, I have a tricky question, which will affect the way xfconf is
> packaged in debian.
> Currently, we have:
> libxfconf-0-0 with:
> - /usr/lib/libxfconf-0.so.0.1.0
> - /usr/lib/libxfconf-0.so.0 -> libxfconf-0.so.0.1.0
> libxfconf-0-dev with:
> - headers, doc etc.
> - /usr/lib/libxfconf-0.a
> - /usr/lib/libxfconf-0.so -> libxfconf-0.so.0.1.0
> libxfconf-0-dbg with debugging symbols
> xfconf with xfconf daemon.
> libxfconf-0-dev, libxfconf-0-dbg and xfconf depends on libxfconf-0-0
> with the same *binary* version (meaning 4.5.91-1 at the moment).
> The xfconf separate package is known to be problematic, because
> currently one can install an xfconf-enabled app (which will bring
> libxfconf-0-0) and not have the xfconf package installed, and thus no
> daemon. This is not good. We have an xfconf dependency in xfce4
> package but it's not enough. So I thought about merging back xfconfd
> into libxfconf-0-0 package, so it's installed as soon as an app needs
> This is what GNOME people do with gconf.
> But then I have a problem with upgrades
> If/when xfconf soname changes, the lib name becomes libxfconf-0.so.1
> and we have to rename the packages to match this, so it becomes
> This is because binary compatibility is changed, and thus old apps
> won't work on the new lib (and new apps won't work on the old lib),
> so we have to manually change the Build-Depends: ont the packages.
> This means we can have two libxfconf installed at the same time, with
> their own set of apps:
> libxfconf-0-0 with old apps
> libxfconf-0-1 with new apps
> Then, I have a problem with the xconf daemon, which is currently
> installed in /usr/bin/xfconfd, and is thus present in both packages
> meaning they can't be installed at the same time.
> GNOME puts the daemon in a versioned directory in /usr/lib to fix
> that: /usr/lib/libgconf2-4/gconfd-2
> So there's no overwrite problem if the soname change.
> But they have a stable soname for gconf since ages, and thus they
> didn't have problems with multiple installations: what if I have two
> xfconf daemon installed. Which one should be started? (the recent one
> yeah, but that needs to be chosen correctly). Anyway I don't think
> the current setup will accept to run xfconfd from /usr/lib, but maybe
> it'd be doable.
> Another solution would be to keep the seperate xfconf package and
> force the automatic dependency. Currently when something is built
> against libxfconf, dpkg automagically adds a dependency on
> libxfconf-0-0 (>= correct version). I could tune that to add a
> dependency on libxfconf-0-0 (>= correct version), xfconf (>= correct
> I'm not sure it's a good idea wrt. debian library packaging
> guidelines, so I'll have to chek this before, but it's an idea.
> Anyway, what is your thoughts about this? I know Xfce apps could be
> upgraded all at once, and thus it should be possible to have only one
> xfconf at a time. But that's ok for Xfce apps. for goodies or other
> application wanting an xfconf backend, it could break. So how should
> be handled those setups?
> Cheers, (and sorry for that long mail. if there's any huge misake in
> there, please forgive and correct me :) )
More information about the Xfce4-dev