* 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. Thanks, Florian