[syslog-ng] Quick question about libsyslog-ng.so.0

[Gergely Nagy]

Hi!

As part of packaging syslog-ng, and splitting it into smaller packages,
I face the problem of having to create a devel package. Now, I could go
the easy way (as I've done with the current set of Debian packages) and
create a syslog-ng-core package, which would contain libsyslog-ng.so.0,
the plugins and the rest, and a syslog-ng-dev package with the headers
and other tools.

This could work, but the downside is that on an automated buildd, one
does not neccessarily want to replace the running syslogd (even if
that's already syslog-ng, which it is in my case) just to be able to
build a package.

So I was thinking about splitting the libsyslog-ng.so library out into
its own package. And herein lies the problem! The SONAME of the library
is currently not set, thus, libtool defaults to libsyslog-ng.so.0. The
problem with this, is that the SONAME will remain the same, even if the
library breaks its ABI underneath. Which will be a problem for any third
party module linked against this library: a new version of syslog-ng
comes out, all of them will break at runtime, in various interesting
ways, perhaps even after days of working, when the module runs over an
incompatible change.

This can be worked around on the packaging level, by ensuring that a new
version of the libsyslog-ng package will conflict with any older
versions, but... that's a pain to maintain, and very fragile.

So instead, I'd like to propose a different way: use the -release flag
of Libtool. This will make the library's SONAME contain syslog-ng's
version aswell, thus, every upgrade will use a different soname (like
libsyslog-ng-3.3.0beta2.so), and modules will break at startup time,
which is much better, as we don't trip over unexpected changes.

It is also tremendously easier to package a semi-private library this
way. (Though, this has a few downsides as well from a packaging point of
view, but considerably less.)

So here I am, seeking input on the issue!

By the way, a third option also exists: maintaining ABI and API
compatibility, and only bumping the SONAME where something did really
change incompatibly. This would be the best option, but this also takes
a lot more work to maintain properly (I'm happy to help with this,
though, I'm already doing this for libmongo-client; but on the other
hand, libsyslog-ng really is something syslog-ng specific, and not a
general purpose library, so it might not worth the trouble to go this
far).

-- 
|8]