[naemon-dev] livestatus commit

[Anton Löfgren]

Are they really, though? Livestatus is the only one I've seen that
does this. Granted, I'm not familiar with a lot of others. I know at
least merlin uses the .so extension, as does all our interally
developed modules at op5 (not that that really matter here, but hey).

The way I've understood it is that the Nagios documentation at some
point suggested that modules should be .o. If that's the case, I
personally feel we should take the opportunity we nevertheless have
with this new project to get rid of that kind of legacy cruft, since
it's completely confusing to anyone _but_ old users. Now, that goes
for a lot of things, and this is hardly the most pressing issue w.r.t
legacy stuff that we have to deal with, but you gotta start somewhere
if we're hoping for Naemon to become something more than simply a
political fork. Not that that's necessarily how I feel, but I've
gotten the feeling at times that we're trying perhaps a bit too hard
to strive for backwards compatibility, and I do feel that that is a
waste, given the potential that Naemon has. I'm not saying backwards
compatibility is unimportant, but I am saying that I would (again, me,
personally) really prefer it if Naemon tried just a little bit harder
to be more than just Nagios with a bunch of (albeit important)
packaging and bug fixes.

Sorry to go off on a tangent like that, it's just something that's
been irking me for a while is all.

On Mon, Apr 21, 2014 at 8:00 PM, Daniel Wittenberg
<dwittenberg2008 at gmail.com> wrote:
> Yes it explains things, basically renaming from .o to .so. which ok makes
> sense in itself, it just might be confusing for other users since all other
> modules are still .o.
>
> Dan
>
> On Apr 21, 2014 12:19 PM, "Anton Löfgren" <alofgren at op5.com> wrote:
>>
>> On 21 Apr 2014 18:22, "Daniel Wittenberg" <dwittenberg2008 at gmail.com>
>> wrote:
>> >
>> > So I've been working on the new Fedora builds, and I saw that
>> > livestatus.o doesn't get built anymore, and looking at this commit:
>> >
>> >
>> > https://github.com/naemon/naemon-livestatus/commit/a44772c48947e8314251f7a90f456054c6bc00e5#diff-480477e89f9b6ddafb30c4383dcdd705
>> >
>> > It appears to be on purpose, so I guess I'm curious what the plan is
>> > with this and how do we get it fixed so we can move forward with the builds
>> > and getting this included in Fedora, I'm also assuming this is breaking our
>> > normal builds too.
>>
>>
>> Hey Dan!
>>
>> It is intentional. A few of us discussed this at some length last week
>> over at #naemon-devel. I would think (or hope, rather) that Fedora
>> prefers objects to be correctly named, either way.
>>
>> The reason for the build breaking is not that the suffix has changed,
>> however. The patchset you linked adds a new dependency in form of
>> libicu which allows us to do filtering with unicode-enabled regular
>> expressions. And there, as they say, is your problem:
>>
>> (https://travis-ci.org/naemon/naemon/builds/23435298)
>> checking for LIBICU... no
>>
>> checking for LIBICU... no
>>
>> configure: WARNING: no pc file found for libicu; then :
>>
>> <snip>
>>
>> g++ -DHAVE_CONFIG_H -I. -I..
>> -I/home/travis/build/naemon/naemon/naemon-livestatus/../naemon-core
>> -g -O2 -MT CustomVarsColumn.o -MD -MP -MF .deps/CustomVarsColumn.Tpo
>> -c -o CustomVarsColumn.o CustomVarsColumn.cc
>>
>> In file included from CustomVarsColumn.cc:28:0:
>>
>> CustomVarsFilter.h:32:27: fatal error: unicode/regex.h: No such file
>> or directory
>>
>>
>> Just adding the correct deps (libicu) to the spec should set things
>> straight. If it doesn't, please let me know and I'll be happy to help
>> out.
>>
>> By the way, without having had a look, if we are shipping a default
>> config containing a "broker_module=<path>/livestatus.o" for naemon, we
>> might want to add a %post that adjusts that path for upgraded system
>> to point at the new livestatus module name. Either that, or add a
>> symlink. Though I'm not personally too fond of the latter approach.
>>
>> As a small digression, I think this is another reason why keeping the
>> spec together with the package (naemon-livestatus in this case) is a
>> good idea. At least for me, it would've increased the likelihood of me
>> adding the dependencies to the spec, since not doing so would likely
>> have caused the build to bomb (directly, instead of indirectly). Just
>> saying.
>>
>> Hope that helps you get things sorted out. And again, don't hesitate
>> to contact me if I can help.
>>
>> /Anton



-- 
Anton Löfgren             alofgren at op5.com
OP5 AB                       www.op5.com