`opm validate` should enforce RFC1123 label requirements on `olm.package.name`
to provide the capability for olm.package.name to be used as a unique identifier in clusters, we need to ensure that it is usable in all cases, including as metadata.name for related objects.
To make it easy to help authors contribute to catalogs consistently, opm validate should fail validation for the case where any olm.package.name violates RFC1123 label constraints.
As a stretch goal, it should also emit a warning if olm.package.name violates RFC1035 label constraints.
As a stretch goal, it should also emit a warning if olm.package.name violates RFC1035 label constraints.
I don't think I agree with that part. That error we saw with a CatalogSource being created with metadata.name being a package name is the problem. If there's a tool that assumes that a package name can be used as a catalog source name, that tool needs to be fixed.
That error we saw with a CatalogSource being created with metadata.name being a package name is the problem.
Agreed, that is a tooling issue and unrelated to this.
This issue is related to v1's desire to utilize validating application policies to ensure clusterextension uniqueness, and the problems attempting to use other keys. (see https://github.com/operator-framework/operator-controller/pull/819)
Solved by #1307