[CentOS-devel] Proposal: Add pkg- prefix to package names in CentOS dist-git

Wed Sep 1 15:32:06 UTC 2021
Florian Weimer <fweimer at redhat.com>

* Josh Boyer:

>> Gitlab has a repository aliasing mechanism.  It could be a gradual
>> transition for existing packages.
> No.  This is extremely excessive.  We already have namespaces, and the
> list of reserved names is already known.  Of that list, there is a
> single one today that actually has an RPM that overlaps.  Adding
> content to RHEL is not a wild west process, so we can control what our
> SRPMs are named as they are added going forward.

Okay, so the prefix isn't going to fly.  The “+” problem is also more
widespread, and the prefix does not solve that at all.

I checked the package addition process, and it actually flows through
CentOS these days (“centpkg import” is used), so it should prevent the
recurrence of the “tree” problem.  Unlike other parts of the tooling,
centpkg seems to know about the “+” rewriting (to “plus”), so that's not
going to help us to prevent future mistakes in that area, though.

What should we do here?  We have a couple of packages that are basically
impossible to maintain in the present state in CentOS Stream.

One possible way forward could be:

* Rename the tree package (starting with Fedora).
* Rename all packages with + in their names (also in Fedora).
* Ban + in future source package names.
* For every REPO, the RPM spec file must be called REPO.spec, and the
  source RPM name must be REPO.

I'm not sure how good RPM is at source package renaming, though.  If the
repository name and the .spec file name and source package name differ
(due to the “+” rewriting or the dump/restore thing), we end up with
tooling issues again (like we had with dump/restore).  If we rename the
package outright, it affects the binary packages as well, and might need
an exception at this point.

My worry is that people have been saying “we'll deal with these few
exceptions manually”, but as far as I can tell, that is just not what's
happening.  RPM components that should be trivially to maintain are
suddenly very difficult.