On 03/30/2016 16:57, Jim Klimov wrote:
2) Why do we want to have mediated /usr/lib/libzmq.so ? It could have
some sense if software could link directly with desired libzmq (for
example, each libzmq lives in separate /usr/libzmqN directory.
Otherwise
I think We could always deliver only symlink to the latest provided
zeromq version, use it to compile all OI-provided software and consider
all other versions provided only for ABI-compatibility, like we do with
libpng.
In libpng scenario we would like to have zeromq meta-package, which
depends on ALL zeromq versions, otherwise we break ABI. Development
files are necessary only for the latest zeromq.
Unfortunately, zeromq family of projects is geared towards continuous delivery and
cares little about compatibility: deployments are expected to 'git pull && make
install'
For example, the project I'm working with uses the malamute broker built on top of libzmq
and czmq. However, there is no "released" version of libzmq that supplies the
needed routines for malamute - only the git head has teh codez. Even though both the git
head and the 4.1.4 released tarball claim ABIv5 and we'd naively expect them to be
compatible. Incompatible API and ABI --breakage-- changes were known in the recent and
distant past of the project - which is still a good and performant MQ middleware library
and ecosystem around it.
For these reasons, I wanted to provide all major versions - because it is not
granted that some particular software (not limited to those with recipes in
oi-userland) will build with a certain version of zeromq AND then with newer
versions too. Conversely, the project web-site encourages existing apps to PORT
from the older stable libzmq 3.* to the new stable 4.1.* - they too do not
expect it to be a plug-and-play change.
I hope these are steps towards better applicability of OI in modern software
ecosystem (e.g. more projects would be easier to build and port onto OI).
In such case I'd delivered different libzmq versions in different
directories, for example, in /usr/lib/libzmq-n and linked software to
the library which it's going to work with (don't forget about RPATH).
Just deliver /usr/lib/libzmq-N/libzmq.so and link software with it. Also
I don't like providing library without providing consumer. For example,
Debian and Ubuntu provide only 2.2.0 and 4.0.5 versions. Both their
packages provide /usr/lib/libzmq.so symlink, but I don't think it's good
when these libraries are not ABI/API-compatible. With such approach it's
hard to say "I want this software to link with this zeromq version".
Perhaps, we can do something like we do for libpq.so - all software we
deliver set -L flags (and perhaps -R) explicitly to use correct
compilation symlink and /usr/lib/libzmq.so is provided only for user
software. As long as SONAME is changed after ABI-incompatible changes,
we'll be on safe side. But we should ensure that our software isn't
linked to "generic" libzmq.so.
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
