Sorry :) I vote same as upstream Dan On Apr 22, 2014 12:23 PM, "Sven Nierlein" <[email protected]> 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 <[email protected]<mailto: > [email protected]>> 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 > > <[email protected]<mailto: > [email protected]> <mailto:[email protected] <mailto:[email protected]>>> > 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" < > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>> 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 < > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>> 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 > > > > > > > > > > > > > > > > > > > > > >
