[naemon-dev] livestatus commit
Max Sikström
max.sikstrom at op5.com
Tue Apr 22 21:31:05 CEST 2014
I'm not actually in the board of the naemon project, so I can just accept
the decisions. I can just have an open opinion, which I have, so here it
is...
First: If naemon is going to use livestatus as interface between
naemon-core and gui/thruk, we can't actually use mk-livestatus without
getting the naemon-interface patched upstream. And since mk-livestatus is
just a part of mk-multisite, which is kept in as a subdir in a single git
repository, it's almost impossible to sync.
Also, if mk-livestatus won't accept new features, even if it isn't used in
mk-multisite, we it won't benefit anyone who want to integrate naemon with
its product. Afaik, the sorting and pagination functionality, which is
quite generic, was rejected, not as implementation but as concept.
Therefore, to make naemon-livestatus useful in installations quite big, if
sorting is expected (which I think is), it mk-livestatus wont suffice.
And to the exteions:
.so is shared object, which is dynamically linked.
.o is an intermediate file, where a .c is compiled, but not linked.
Sometimes called "program object file"
.a is a statically linked library, which can be linked upon at compile
time, and then kept in the binary
.l* is the same as above, but wrapped in libtool, so .la is a libtool
static library, normally used internally as an intermediate step when
building the binary to ship.
Mixing .o and .so would be like taking a something.docx document, call it
something.txt, since it contains text. It will probably still open in word,
but it isn't correct. It has been wrong since the epoch in the nagios
world, but why not make it correct?
So I like the concept of not explicitly breaking .o in the filename, since
it's just a filename. But if it is a .so file, name it as such. If the
naemon-suit is going to build from upstream repo, it will probably contain
a patch queue, and this is one of those patches I would like to have;
keeping it correctly named.
To see what livestatus.o contains: (build locally)
$ file livestatus.o
livestatus.o: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, not stripped
Compared to a "normal" .o-file:
$ file livestatus_so-Column.o
livestatus_so-Column.o: ELF 64-bit LSB relocatable, x86-64, version 1
(SYSV), not stripped
Which doesn't say "shared object" or "dynamically linked". It says
relocatable (PIC), which is nessecary to use in a .so however.
Regards,
Max Sikström
On Tue, Apr 22, 2014 at 8:36 PM, Daniel Wittenberg <
dwittenberg2008 at gmail.com> wrote:
> Sorry :) I vote same as upstream
>
> Dan
> On Apr 22, 2014 12:23 PM, "Sven Nierlein" <Sven.Nierlein at consol.de> wrote:
>
>> I am confused now. Upstream is '.o', we changed to '.so'.
>>
>>
>> On 4/22/14 19:04, Daniel Wittenberg wrote:
>> > I was leaning toward the "o" and not "so", but it does concern me a bit
>> now that Sven pointed out upstream is still "so" and that could get really
>> confusing, we already have our own version of livestatus, and to add our
>> own file extension would make things confusing as well. I guess at this
>> point, since we have been trying to figure out how to merge with upstream
>> and get back to one version, I think we should stick with "so" until all
>> that is worked out and go with whatever upstream is.
>> >
>> > Dan
>> >
>> >
>> > On Tue, Apr 22, 2014 at 9:45 AM, Anton Löfgren <alofgren at op5.com<mailto:
>> alofgren at op5.com>> wrote:
>> >
>> > I suppose it goes without saying that I'm strongly opposed to the
>> idea
>> > of (re-)introducing the previous hackery to do things wrong.
>> >
>> > It's got nothing to do with it being "the op5 way". It's got
>> everything
>> > to do with not going out of our way to make things more confusing
>> than
>> > they need to be. In essence, my argument is: look in your /usr/lib/
>> > directory and see if you can find a single shared object that has
>> the .o
>> > extension (that isn't a nagios/naemon broker module).
>> >
>> > I really feel that this is the wrong time to be adamant about
>> backwards
>> > compatibility, since it doesn't in any practical sense affect users
>> in
>> > any way we can't deal with.
>> >
>> > Sedding the config file on upgrade is perfectly acceptable in my
>> > opinion. Especially for a piece of software that is not even 1.0!
>> > Remember how we refrained from releasing 1.0 to be able to get rid
>> of
>> > old cruft? This is it (or, some of it).
>> >
>> > The one point I might agree with is that the documentation would be
>> > marginally misleading. Is this really (I mean, really really) a
>> problem,
>> > however? Presumably, we're offering a suite with batteries included
>> to
>> > use naemon-livestatus, and I'm guessing that includes the one
>> relevant
>> > part of the documentation you're referring to, namely that
>> > broker_module=<path>/livestatus.o should be
>> > broker_module=<path>/livestatus.so. I don't see how this is any
>> harder
>> > than simply adding a disclaimer to the docs pointing out this
>> > discrepancy. Besides, it's not like the livestatus documentation is
>> > fully reliable with naemon-livestatus as is, anyway. The fork
>> exists for
>> > a reason.
>> >
>> > I have not heard of any effort to get anything upstreamed. Do you
>> have any
>> > more details on that?
>> >
>> > Anyways, this feels a bit like an uphill struggle for myself, since
>> I'm
>> > not really mandated to decide or vote either way. Regardless,
>> that's my
>> > take on it. If the core team decides differently, I'll begrudgingly
>> > accept that decision.
>> >
>> > /Anton
>> >
>> > On Tue, Apr 22, 2014 at 02:58:13PM +0200, Sven Nierlein wrote:
>> > > So how do we proceed here? I'd like to see working builds again.
>> So can
>> > > we just keep it livestatus.o and do not break everything. This
>> would save
>> > > us from sed hacks in our packages and confused users. Unless we
>> want
>> > > to copy all livestatus documenation and replace livestatus.o with
>> livestatus.so
>> > > there too? Definitly not a good idea. In fact, i thought we would
>> try to
>> > > get our changes upstream so we don't have to maintain our own
>> livestatus
>> > > anymore? This rename just makes things more complicated, so we
>> would
>> > > have to do the same sed hackery again when we switch back to the
>> original
>> > > livestatus, or is this no longer an option?
>> > >
>> > > So i would rename livestatus.so back to livestatus.o in the
>> naemon-livestatus
>> > > Makefile and keep the path %{_libdir}/%{name}/livestatus.o. This
>> is an easy
>> > > change and does not break anything except its not the op5 way. And
>> > > honestly, i don't care about that.
>> > > Does anyone have a better solution?
>> > >
>> > > Sven
>> > >
>> > >
>> > > On 4/21/14 22:20, Daniel Wittenberg wrote:
>> > > > It looks like the path also changed, was that on purpose too?
>> > > >
>> > > > From:
>> > > > %attr(0644,root,root) %{_libdir}/%{name}/livestatus.o
>> > > >
>> > > > To:
>> > > > %attr(0644,root,root)
>> %{_libdir}/%{name}/%{name}-livestatus/livestatus.so
>> > > >
>> > > > I've got the changed staged to fix up the spec file, probably
>> want to add a search/replace in the spec to update the config from
>> livestatus.o to livestatus.so too, but will get this out there first to fix
>> our builds.
>> > > >
>> > > > Dan
>> > > >
>> > > >
>> > > > On Mon, Apr 21, 2014 at 2:56 PM, Anton Löfgren <
>> alofgren at op5.com <mailto:alofgren at op5.com> <mailto:alofgren at op5.com<mailto:
>> alofgren at op5.com>>> wrote:
>> > > >
>> > > > Naemon doesn't care either way as long as the correct path
>> is configured, which it will be even for existing users as long as the post
>> step I mention earlier is in place.
>> > > >
>> > > > I'm not suggesting we start enforcing any kind of
>> convention just for the sake of it.
>> > > >
>> > > > /Anton
>> > > >
>> > > > On 21 Apr 2014 21:41, "Daniel Wittenberg" <
>> dwittenberg2008 at gmail.com <mailto:dwittenberg2008 at gmail.com> <mailto:
>> dwittenberg2008 at gmail.com <mailto:dwittenberg2008 at gmail.com>>> wrote:
>> > > >
>> > > > I'm not sure I have a strong opinion either way, just
>> that if we decide we want to change it, or even consider it in the future,
>> now is the best time to do it. Can we have it use either .o or .so and
>> just have livestatus be .so for now? That would allow backwards
>> compatibility but move in the direction we think we should ?
>> > > >
>> > > > I updated the Fedora build to use .so for now so at
>> least the builds are going again.
>> > > >
>> > > > Dan
>> > > >
>> > > >
>> > > > On Mon, Apr 21, 2014 at 2:18 PM, Sven Nierlein <
>> Sven.Nierlein at consol.de <mailto:Sven.Nierlein at consol.de> <mailto:
>> Sven.Nierlein at consol.de <mailto:Sven.Nierlein at consol.de>>> wrote:
>> > > >
>> > > > Hey,
>> > > >
>> > > > Basically every ndo module uses .o extension. At
>> least ndo,
>> > > > mod-gearman, dnx and livestatus. Thats all i know.
>> > > > This change screws every existing naemon
>> installation. Not that
>> > > > there are so many yet, but we should be very
>> careful when changing
>> > > > fundamental things. So if the only reason for this
>> change is, that
>> > > > this is more correct in terms of describing the
>> file content, i'd vote
>> > > > for keeping things like they are unless we have a
>> good reason
>> > > > to change that.
>> > > >
>> > > > Sven
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/naemon-dev/attachments/20140422/45a3ede6/attachment.html>
More information about the Naemon-dev
mailing list