...
This was spawned by the conversation started on the initial r10k prototyping work PR.
As a corollary, we should probably take a good hard look at what the RPM is doing in the %post section and determine if this is actually still necessary and/or should be in this RPM instead of in the simp config command or the like.
Options considered
| Option 1: | Option 2: | Option 3: |
|---|
| Description | Persist the simp-adapter-foss and simp-adapter-pe installation packages with puppet dependencies. | Push all puppet dependencies down to the individual modules | Push all puppet dependencies into the simp RPM. |
|---|
| Pros and cons |  Allows for a two-package installation of the entire stack if your repositories are set up correctly.
 Having simp-adapter-pe gets confusing and tends to win in the YUM repos. It should probably be isolated into its own repo if this path continues.
| Probably the most accurate mechanism May allow for a one-package installation with yum install simp May have to persist a package to version matrix to determine what version of puppet is in what upstream package. Will probably require a re-roll of all modules with a version bump just for this. (If so, this should wait until after 6.4.0 so that we can get the r10k work completed) | Allows for a one-package installation with yum install simp Eliminates the possibility of installing individual components via RPM without dragging in the entire stack and reduces the simp RPM relevance as a pure meta-RPM (yes, a lot of the stuff in the %post section already needs to be refactored and/or removed but this would make the problem worse) Would change a lot of long-held RPM couplings and require the most amount of testing to achieve and should wait until after 6.4.0 if selected. |
|---|
| Estimated cost | | | |
|---|
...