I've been talking about this with @kevin but we haven't come to any conclusions about what it would take to do basic validation and automatic approval, IIRC ...

The review guidelines already have an exception to allow multiple versions of the same package.

https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

The mechanics of new dist-git repo creation are handled by releng, not the packaging committee. I think we should just close this issue in favor of a releng issue.

https://pagure.io/releng/issues

I agree. And to note, the issue is really just doing some basic checks and ensuring that the naming guidelines for this type of package is followed. I think it's doable but not entirely trivial.

Right now one of a group of people (which includes me) will check these and I have spotted issues. In fact, there are some packages pending now which do not meet the naming guidelines. This isn't something that can just be auto-acked with no checks being done.

Finally, are the SCM admins really that slow? If someone pings me in IRC or email, I will certainly be happy to process any outstanding requests as long as I am near a computer.

My proposal is that it should be auto-acked with automatic checks. My original post contains, implicitly, one of the proposed checks: that it should only be auto-acked if it conforms to a particular naming scheme, the one that matches the format for a rust compat package. That constraint can certainly be checked automatically.

It's not entirely obvious how to automatically check for valid package name. There are two schemas for naming compat packages, depending on whether the last character of the original package name is a digit or not.

For example, compat packages for the git2 crate (rust-git2 package) are rust-git2_0.16, rust-git2_0.14, etc., while the compat packages for the libgit2-sys crate (rust-libgit2-sys package) are libgit2-sys0.14, libgit2-sys0.13, etc.

Stripping only (_)?([0-9]+|0\.[0-9]+) from the end of a package name to determine the "base package name" might be sufficient - but there are also edge cases where this will have undesired consequences - for example, both the net and net2 crates exist, and both socket and socket2 exist (luckily we haven't had it occur that we needed a compat package for version 2 of crate foo but crate foo2 was already packaged ...).

If you can come up with an algorithm that correctly determines the "base package name" from a compat package name without falling afoul of these edge cases, we can discuss automating approvals with that logic. I'm not sure whether part of that validation should also be that the requester of the compat package is also the owner (or co-maintainer) of the "base name" package, but I think it would also be a good idea.

So, there are two different schemes for adding the legacy package suffix:
1. If the base package ends in a number, + '_<major>.<minor>'.
2. If the base package ends in not-a-number +'<major>.<minor>'

So, we have perhaps, "net" and "net2" packages, and we have perhaps, to make legacy version with major=2 and minor = something for net. Then "net" -> "net2.<something>" for the legacy package, and the concern is that it would be confused w/ net2 package, because it has the identical prefix.

I'm pretty sure something could be done to unambiguously distinguish the the legacy suffix from the package name and I could devote some time to figuring what that is.

What I don't understand, though, is how this fits into the larger picture. You obviously want to strip to get the original package name. But what are you matching that original package name against and why?

So, there are two different schemes for adding the legacy package suffix:
1. If the base package ends in a number, + '_<major>.<minor>'.
2. If the base package ends in not-a-number +'<major>.<minor>'

Yes, but additionally, the .<minor> part is only added iff <major> is not 0. And there's also the possibility of having rust-foo0.0.x for compat packages for versions < 0.1.

So, we have perhaps, "net" and "net2" packages, and we have perhaps, to make legacy version with major=2 and minor = something for net. Then "net" -> "net2.<something>" for the legacy package, and the concern is that it would be confused w/ net2 package, because it has the identical prefix.

I think we can disregard name collisions for now. They haven't happened in the last 8 years, it's unlikely for them to happen soon.

I'm pretty sure something could be done to unambiguously distinguish the the legacy suffix from the package name and I could devote some time to figuring what that is.

Maybe, but that would involve changing the Naming Guidelines for compat packages entirely.

What I don't understand, though, is how this fits into the larger picture. You obviously want to strip to get the original package name. But what are you matching that original package name against and why?

We need to get the original package name to check whether it exists. Otherwise you could just request rust-foo9001, it would be a valid name for a compat package, but if rust-foo doesn't exist, it still shouldn't be approved.

I'm pretty sure something could be done to unambiguously distinguish the the legacy suffix from the package name and I could devote some time to figuring what that is.

Maybe, but that would involve changing the Naming Guidelines for compat packages entirely.

You misunderstand me there. I mean, when confronted with a package name, + version, determine what parts, if any, were the legacy suffix. So, I'm not proposing changing these naming guidelines.

What I don't understand, though, is how this fits into the larger picture. You obviously want to strip to get the original package name. But what are you matching that original package name against and why?

We need to get the original package name to check whether it exists. Otherwise you could just request rust-foo9001, it would be a valid name for a compat package, but if rust-foo doesn't exist, it still shouldn't be approved.

How, given the package name was correctly extracted, would you do this check? That's the part I don't understand.

A simple check would be whether HTTP GET https://src.fedoraproject.org/rpms/<package> returns an HTTP 200 OR 404 response ... but that does not account for retired packages, so checking for the existence of a spec file on the rawhide branch would be even better.

In fact, rust2rpm already implements such a check when looking for an existing package for a given crate name.