[oi-dev] zeromq versions

[Jim Klimov]

30 марта 2016 г. 16:37:00 CEST, Alexander Pyhalov <alp at rsu.ru> пишет:
>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.

Going forward, I guess that realistically we should provide the newest version (even if at the moment these are random snapshots from the git head, if that is the only up-to-date code that modern projects can build against, and even if there are no upstream guarantees on future backwards compatibility) of the shared library and corresponding headers in the common OS locations. Mediated links and bulk delivery into /usr/share/zeromqN (where N is the claimed ABI version, not package version, at the moment), as done in those PRs, seem to achieve this goal.

For older third-party projects that have not yet converted ans must consume older stable versions of libzmq (and which IMHO do not necessarily have to magically instantly appear as part of our gate) - we can provide the latest in each named release-branch (3.2.* 4.0.* 4.1.* so far) to facilitate convenient use of OI as the platform for such projects. Again, the PRed structure suffices for that, almost.

If I get your point correctly, you'd rather not deliver the non-newest shared libs into /usr/lib/$(MACH) and keep them under /usr/share/zeromqN/lib ? Is that the only big difference?

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android