Update SIMP Repository and RPM Naming Scheme

Background

Restructure the current and future SIMP modules and RPM (metadata) names to match community utilized structure, making our repositories and RPMs easier to manage, maintain, and understand.

Relevant data

Github repositories will be re-named to fit a more readable, community utilized structure. The word ‘pupmod’ will be removed, and replaced per the structure below. The word ‘simp’ will also be removed unless absolutely necessary.

Structure

• All puppet modules will be named ‘puppet-<module_name>’
• All rubygems will be named ‘rubygem-<module_name>’
• All other types will be named ‘simp-<module_name>’
• OPTIONAL: All repositories will contain only one dash, with longer names containing underscores; i.e 'puppet-<extra_long_name>'

Examples:

• ‘rubygem-simp-cli’ would become 'rubygem-simp_cli’ or stay the same
• ‘pupmod-simp-simp’ would become ‘puppet-simp’
• ‘pupmod-simp-simp_apache’ would become ‘puppet-simp_apache’
• ‘pupmod-simp-auditd’ would become ‘puppet-auditd’
• ‘simp-doc’ would stay the same

Update RPM Naming Scheme

Repositories would have their metadata.json or <name>.spec files updated to match the name of the repository. There will be no instances where an RPM name does not match the upstream repository name. 

Modules that we have forked from other organizations will match the same structure listed above. We will not reference the upstream organization in the module or the RPM.

1. If we are forking a repository and making changes, we should assume control/maintenance and not put the other organizations name in an RPM that they did not build.
2. If we are forking a repository and NOT making changes, we will use the upstream repository as a Third Party Asset rather than building it as a SIMP RPM that we didn't write the code for.

         ** If our fork does NOT contain changes, we can maintain the fork if we are worried about losing the upstream, but we should have it as a backup, not as the source code in builds. 

To ease concerns regarding the restructure of our Github Repositories, I've already reached out to Github, and they verified that they have permanent redirects on all name changes, and the only way they will ever be removed, is if the owner of the repo reaches out to them and asks for it to be removed. All links to the previous names would still work after the name changes.

This plan will result in a minor version bump for all updated modules since we would be changing the metadata.json or .spec file to update the names, as well as changing any dependencies to match the new naming scheme, adding obsoletes to prevent issues with the name change. If no changes are needed to the name, metadata or spec, or obsoletes, no version bump would be necessary. 

Options considered

Action items

• Update SIMP Repositories to match naming scheme if necessary
• Update metadata.json or .spec file to match naming scheme if necessary
• Add necessary obsoletes
• Update code to fix references to old names
• Minor version bump for Repositories that had metadata.json or .spec file updates
• Update documentation to match the new naming scheme

Outcome