Determine if adding the OS qualifier to the RPMs would be beneficial
Add your comments directly to the page. Include links to any relevant research, data, or feedback.
Status | NOT STARTED |
|---|---|
Impact | LOW |
Driver | @Trevor Vaughan |
Approver |
|
Contributors | @Chris Tessmer @Dylan Cochran (Unlicensed) @Brandon Riden (Unlicensed) @Kendall Moore @Liz Nemsick @Judith Johnson @Shark Bruhaha (Unlicensed) @Michael Morrone @Jeanne Greulich |
Informed |
|
Due date | Apr 26, 2019 |
Outcome |
Background
Traditionally, the SIMP RPMs were packaged where the %{dist} tag was omitted if the package had nothing that bound it to the release and included if there were distribution specific items in the RPM spec file.
Over time, this has shown to cause some difficulties around release time in that you may end up with the same package built and released twice for EL6 and EL7 when it should not have been. When you then go to point at an upstream repo, you will get YUM issues where it finds that the upstream package.
Relevant data
RHEL and its derivatives have gone to just rolling in the %{dist} tag no matter what to make everything easy to maintain.
Options considered
| Option 1: | Option 2: |
|---|---|---|
Description | Leave things the way they are | Add the |
Pros and cons | Fewer builds (only one instead of two or more) Already done If we don't get it 100% correct all the time, we run the risk of having the same RPM with different checksums in the associated yum repos and/or ISOs. | There is no question what something is built for Easy to validate that you've gotten it right both visually and automatically. Able to release different OS versions independently without worry. Have to roll an additional RPM for each platform (this is already automated) |
Estimated cost | TRIVIAL | LOW |
I honestly feel like this decision depends on how we handle the building/releasing of RPMs.
If we are tagging modules as they are merged, and building RPMs as the modules are tagged, I feel like Option 1 is the best way, since we can automate the building, and either automatically or manually sign and push the RPMs to the necessary repo. Then when we build, it'll grab the necessary packages and we won't have an issue with the same file having different checksums. The only potential issue I see is something like simp-doc, but we could figure out a solution for that.
If we are relying on the build process (build:auto or pkg:modules) to create the RPMs that we would sign, then push, I feel like option 2 would be the best option since it would be quicker and more beneficial to build at the same time, or back to back, rather than having to build EL7, then extract everything, sign them, upload them, then rebuild EL7 and then build EL6.
Regardless of the decision the final RPMs (simp and simp-doc) will both need to be pushed up late in the build process, so we would just have to make sure we aren't pushing separate files there.