[RFC][RPM (or general) packaging] monolithic packaging is unbearable for more fine-tuned deployment scenarios

[jnpkrn]

Since the upstream project sets primary expectations about how the final bits shall be distributed in a form of RPM package(s), it's vital that such a trend is set to meet various (possibly competing) expectations.

The only such expectation that is now fully satisfied can be summarized:

it is convenient to deliver both what constitutes unpronounced but de facto standard library for implementing resource agents in POSIX shell (modulo local, and now possibly also in Python) and a (sub)set of such maintained implementations hosted within the project (let's call these native), in one go

This is effectively biased against other, competing use case:

the HA cluster to be deployed does not use any native resource agents, HOWEVER, the agents to be in active use vitally depends on said "standard library" part from the project

Apparently, for such a use case, it may be an uncomfortable overkill to install all the agents, especially since it currently gets noticably amplified that all the run-time prerequisites of every and each such agent is dragged in as well.

We can even put a more distant horizon in the picture. Perhaps the ultimate goal would be to enclose each agent on the project in a subpackage on its own, bringing a true at-will granularity. This approach is currently implemented with a sibling fence-agents project and I am not aware of any bad fallout of such a cut.

But let's start small, I propose this split (exact names to be decided, mostly for illustration):

• resource-agents-lib-shell
• resource-agents-lib-python
• resource-agents

First two are self-explanatory, and these would preferably be noach. The last one will likely remain arch-specific for the time being, and will comprise all the agents as before, minus files placed in the former two.

Case in point: booth-site package would effectively require just resource-agents-lib-shell, avoiding incuring all agents + their dependencies to be installed. Hence noticably saving precious space in the static container images, for instance. Not to speak of situations of interdepency issues -- now such graph would be rather minimal, lowering the probability of getting stuck in case of "permanent flux" distros, for instance (say Fedora Rawhide).

Currently, consider this widely open "RFC" type of inquiry, I can follow with the actual implementation if there's a consensus.

[jnpkrn]

Note that, in the envisioned split, the effect of

[repomanager of choice] [install command] resource-agents

would remain exactly the same, as (presumably) resource-agents would depend on both resource-agents-lib-shell and resource-agents-lib-python (borrowing the suggested names).