[oi-dev] zeromq versions

[Alexander Pyhalov]

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