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 > > > > > > > > > > > > > >
