fixed build

[shaitan]

Use blackhole-dev (= 0.2.3-1) in dependencies because new blackhole v1 has the same name of dev package.

[bioothod]

There is 0.2.4-1 already as well as 0.2.3-2

[shaitan]

As @3Hren said, there is no important (critical) change in these two versions, so it will be ok to use 0.2.3-1. When it will be possible, we migrate to new blackhole v1.

[3Hren]

Okay, here the changelog: 0.2.3-2 fixes build on GCC 5+ 0.2.4-1 fixes build with boost::variant 1.59+ by workarounding broken boost behavior.

You can freely chose whatever version you want of these three.

[shaitan]

I have no preference about the version. @bioothod, do you have any?

[bioothod]

It is unlikely to migrate to newer version anytime soon, since there is a huge number of projects depending on elliptics/thevoid which use v0.2

I would prefer the latest version, i.e. 0.2.4-1, others fail to compile on recent distros

[shindo]

TheVoid will safely migrate to Blackhole v1 with major version bump (i.e. it will be TheVoid v4).

[bioothod]

It is not that simple, application which depends on thevoid and elliptics will have to determine somehow to use either older elliptics and older thevoid or new thevoid and newer elliptics. It is not just >> thevoid4-x.x.x., since there will be, let's say, 2.26.10.0 elliptics which still matches all version checks but is already incompatible with thevoid logger.

I would like to move to newer logger in elliptics and check what breaks, since otherwise it will never happen at all.

[shaitan]

I have updated the commit, now it only adds upper limit to version of blackhole-dev.

[3Hren]

This is a mistake.

Given an elliptics has been built with 0.2.0 suppose that there are clients, that depend from libelliptics, which are build with 0.2.1 and 0.2.2 (this is valid, because of soft constraint).

Every version of a header-only library should be considered as a static library, which you are compile into your library, providing symbols outside (or not).

As a result we have clients which has been build with wrong version and that linked with elliptics to be able to work with. Because of there are no inner namespace resolution between those symbols (in v0.2) we have a terrible symbol loading race, which is UB.

[shaitan]

Branch v0.2 of blackhole should not be updated with changes that will break compatibility between versions.

[3Hren]

Depending on what do you mean by compatibility. Even if there are no API/ABI breaks in v0.2, still some function implementation changed, which violates ODR in case of linking together libraries built with several Blackhole versions.

[shaitan]

I've done it again, I've returned exact blackhole version in dependencies and changed it to =0.2.4-1. Since blackhole is header only, any change to its' code should be considered as breaking thing and we have to fix its' version in dependencies. The dependency should not be changed until we are ready to move to newer logger.

[bioothod]

I merge this pull request, but I would like to move to blackhole v1.0, @shaitan what do you think, how long will it take to update your projects?