Tricky question about libxfconf, xfconfd and soname

[Brian J. Tarricone]

Corsac and I chatted about this on IRC, so no need to reply.  The
summary is:

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.

	-b

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
> xfconf.
> 
> 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
> libxfconf-0-1. 
> 
> 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
> version).
> 
> 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 :) )