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

Mon Sep 6 07:41:02 UTC 2021
Kamil Dudka <kdudka at redhat.com>

On Wednesday, September 1, 2021 5:32:06 PM CEST Florian Weimer wrote:
> * 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).

I have initiated the package rename request in 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