why nagios installs in /usr/nagios? root@blight usr # ls nagios/ bin/ contrib/ sbin/ share/ root@blight usr # can't it use / as root?
I think the orginal idea behind it was because nagios has a specific set of things and if you installed in root with all separate directories, things got confused. This way, everything pertaining to nagios is in one place and easy to find.
ok, but this is a windows-like politics. so..you should add a /usr/gtk, /usr/gtk2, /usr/nessus, /usr/apache... it's useless to continue, i'm sure you understood. i think placing nagios is /usr is not really standard, and, as other apps don't do that, it will result in a strange behavior in the gentoo system. it may create problems for 3rd parts scripts or apps... not harmonic i mean.. that's why i posted the bug. please merge in / as root.
I agree that its not in the norm for other applications we have. I really don't knwo why the original maintainer decided to build it that way, I don't think he's still around or I'd ask. If we do change it, that will potentially create problems for people who already have nagios installed and configured for the other path. I'm not really ready to make that kind of change yet without investigating all the issues behind changing it. Other than the argument about making it 'standard' what other advantage would there be moving it? I'm a firm believer that "if its not broken, don't change it", and would hate to see all the bugs/complaints about things breaking because of a move like this just to make it 'standard'.
i don't think it could create lots of problems. consider that /usr/nagios is not in the default PATH, so you need to add it or use absolute path to use it... it contains lots of html,css and images, maybe an apache integration could be usefull. the "don't touch to be sure it works" is the opposite of "let's improve it" , or let's clean it... it should be: "let's investigate before a certain move action" :)
now that new apache hier is supposed to be stable, let's clean up this one. alpha ebuild will follow later.
Created attachment 68856 [details] alpha version of improved (hopefully) nagios-core it does *NOT* work as you expects. lots of TODOs and BUGs in the ebuild, suggestion, opinion and compalins are welcome.
Created attachment 68916 [details] nagios-core-2.0b_p2-r1.ebuild TODO: test in new apache hier modify other nagios-* suggestion?
Created attachment 68917 [details] nagios-core-2.0b_p4.ebuild nagios-core-2.0b_p4.ebuild bug #88760
Created attachment 69003 [details, diff] more-comments.patch a patch to nagios-core-2.0b_p2-r1.ebuild nothing but more comments, no new function, to explain why I did what I looked at old bugs related to nagios, if you know what I'm missing, please comment.
Wow, thanks for looking into that. I'll see if I can play around with your patches when I get a chance.
I did some research on it concerning a move to / and I have to say that it is a bad idea in this case. We would have to spread parts of it over the whole system which would make it hard to find every component when using plugins. So I would vote for leaving it in /usr/nagios
you're thinking like this: "it works, so no problem" the idea should be: "ok, now it works, but should be fixed as it's not a standard way." i understand some packages should be changed, but that's not a good motivation to keep it like that. ihmo!
Nagios 2.0rc2 has been released. except for the lack of documentation of event broker API, it's quite stable. upcoming next major version bump will be nice opportunity to fix this bug.
(In reply to comment #12) > the idea should be: "ok, now it works, but should be fixed as it's not a > standard way." I agree partly. In general you're right, but in this case it will require that any user who would like to extend it by plugins/scripts available on the net has to fight with it the same way and I'm not sure if that is the target of what we should do. There are many programs (would even say nearly all) where it makes sense to get them integrated in the normal system but not this one.
Standards exist for the purpose of making things easier for everyone. For nagios, it seems that using stardards will not make it easier. In fact, it will add complexity on the maintainer's side and the user's side. Fixing this package so that it complies to standards just for the sake of complying to standards and not to facilitate the usage of the tools is pointless. dont_change_it++;
I'm going to agree with most everyone here. While standards are there to make things simple, I don't think it will make nagios more simple to manage. Until I see any good points that support improvement outside of the file locations, I don't see this change happening. I really haven't seen any outstanding problems thus far with our current setup outside of being the 'norm'. Upstream even shows installing it in its own directory (though /usr/local/nagios). Gentoo doesn't install anything in /usr/local so the next best option to hold to upstream is the solution we used.
why is it that hard to manage? any other distribution that has same hier policy? a quick search result from http://www.google.com/search?q=/usr/nagios+-gentoo shows there are few.
You even said it yourself, other distros do the same.
Thanks, you explained a lot.
