Hi Lance,
yeah, I have used /opt/check_mk_agent/ in a couple of different ways at a previous job and it just made so much sense to have it somewhere in /opt rather than in an unpredictable place somewhere in /usr.
It seems your idea about splitting things out makes sense as long as it’s managed centrally.
Hmmm that’s not really what I’m getting at. It would still be packaged and deployed as usual, and anyone can then overlay the base package install with custom local checks, plugins etc however they please - bakery, ansible, rsync… whatever works for them.
Splitting the agent code out is more about code manageability and setting a foundation for potential future improvements. The merged agent script is getting up to 3k lines, is a bit unwieldy and it still has room to grow i.e. where it has capability for Linux that needs to be filled in for Solaris, AIX etc. I know from experience that if this is genuinely followed, then this can massively blow out the amount of code 
It’s also about being able to make commits to the git repo in relative isolation. At the moment I have something like half a dozen PR’s sitting there, I also have a massive backlog of commits to throw in but, frustratingly, I’m kinda blocked by those PR’s - I can’t really commit any further without invoking merge conflicts. With things split up, I - or anyone else - can simply have a branch per target item and queue up whatever number of commits I like.
I’m also trying to set some groundwork for untangling the mess of how MRPE, local checks, plugins, inventory scripts and whatever else are handled.
As demonstrated above, it also opens up the opportunity to throw in a bunch of code to generate ndjson structures that the server side can process with plain old json libraries, rather than check_mk’s somewhat fragile looking incumbent standard.
But, as far as central management goes, I am leaning towards introducing a couple of config files. I discuss one here which could be actively centrally managed or not… and I’m still forming my ideas about the other one, but at this stage I’m envisioning it being one that you can optionally manage.
That linked config file standard is an improved descendant of how I recall managing local checks in /opt/check_mk_agent at my previous employer. I settled on its syntax probably 5 or 6 years ago specifically to deal with customers who used Ansible, Puppet etc and customers who had no config management at all (i.e. you can craft a single monolithic file and deploy it… however… just as you can with sudoers)
Perhaps there are other avenues like having monitored hosts pull their configs down, maybe via the newfangled api? Or the bakery… I don’t know 
I don’t think any repos should include the check_mk agent.
Absolutely agree To the rest of your packaging issues, at my aforementioned previous employer we’d just use yum-versionlock. Single line change in the ansible inventory, then go on with your life 
Thanks for the feedback, though, it’s nice getting a break from the radio silence