[naemon-dev] livestatus commit
Daniel Wittenberg
dwittenberg2008 at gmail.com
Tue Apr 22 19:04:43 CEST 2014
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> 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>> 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>> 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>> 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
> > >
> > >
> > >
> >
> >
> > --
> > Sven Nierlein Sven.Nierlein at consol.de
> > ConSol* GmbH http://www.consol.de
> > Franziskanerstrasse 38 Tel.:089/45841-439
> > 81669 Muenchen Fax.:089/45841-111
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/naemon-dev/attachments/20140422/b487d87d/attachment-0001.html>
More information about the Naemon-dev
mailing list