Quick question about libsyslog-ng.so.0
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]
On Sun, 2011-08-21 at 12:48 +0200, Gergely Nagy wrote:
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).
I was thinking about this issue just the other day, and I was wondering if it'd make sense to move libsyslog-ng.so to $prefix/lib/syslog-ng, as it is more a private library. But this would require setting LD_LIBRARY_PATH or -rpath in the syslog-ng binary. So this was a no-go. Also, the .so only needs to exist because of linker pecularities. If we focused on Linux only, it'd not be needed at all. (symbols could get resolved through the main program only, but this doesn't work on non-ELF platforms, and could have problems on some ELF platforms, like Solaris). -release would help, since even if it is included in $prefix/lib, it'd clearly be visible that it is release specific. However the same problem applies to modules too: there's only a single syslog-ng plugin directory, and if some plugins are compiled against a different core, they'd get into the same dir. What about doing this: * libsyslog-ng.so is linked with -release $VERSION * the module directory (plus search path) is set to $prefix/lib/syslog-ng/$VERSION This way, the set of modules that would actually work would be cleanly separated. Except for the -release change, the module directory could be used this way by merely specifying options for the configure script by "debian/rules". I would like to overwrite binaries if one compiles from source (except maybe libsyslog-ng.so). -- Bazsi
Balazs Scheidler <bazsi@balabit.hu> writes:
I was thinking about this issue just the other day, and I was wondering if it'd make sense to move libsyslog-ng.so to $prefix/lib/syslog-ng, as it is more a private library. But this would require setting LD_LIBRARY_PATH or -rpath in the syslog-ng binary. So this was a no-go.
LD_LIBRARY_PATH may work, so would dropping a file in /etc/ld.so.conf.d/ on modern Linux distributions (Debian included), but it's certainly not nice, and too fragile. -rpath is no-no. If for nothing else, then because Debian Policy forbids it. :P (Another option would be a wrapper script, but that's another dirty hack)
-release would help, since even if it is included in $prefix/lib, it'd clearly be visible that it is release specific.
However the same problem applies to modules too: there's only a single syslog-ng plugin directory, and if some plugins are compiled against a different core, they'd get into the same dir.
I don't see plugins as a problem: if they link to an incompatible libsyslog-ng, then dlopen()ing them will fail, and that's already handled reasonably gracefully: it will either be skipped (if it's loaded, but unused otherwise), or syslog-ng won't even start, and will display an error message. For me, that's acceptable, because I'll make sure at the packaging level that this does not happen, that any third party module that might be available as a Debian package, will not be co-installable with an incompatible libsyslog-ng: one would need to upgrade both at the same time. The plugin issue with a libsyslog-ng.so.0 was that plugins could still load, as symbols will likely be able to resolve, but if the ABI broke otherwise, we'd be up for a nasty surprise past loading. With -release, even the load will fail, and that's good enough for me ;) But the versioned module dir you outline below, is another safeguard. Though, if a module should be loaded, but is in a different dir, syslog-ng will still not start, so we didn't gain that much. Except that it's clearer which module belongs to which version, even without a package manager present. That's probably a good thing on platforms other than the ones I care about =)
What about doing this:
* libsyslog-ng.so is linked with -release $VERSION * the module directory (plus search path) is set to $prefix/lib/syslog-ng/$VERSION
This way, the set of modules that would actually work would be cleanly separated.
Sounds good. -- |8]
participants (2)
-
Balazs Scheidler
-
Gergely Nagy