Won't this break existing packages that use %{goname} for the name of the source package?

Testing is in progress.

The goal would be to recreate new repos and retire the older ones.

Won't this break existing packages that use %{goname} for the name of the source package?

Yeah, I was about to write the same thing.

We cannot change this without breaking many packages. If we decide to go ahead with this change, it needs to be opt-in. I don't think it's worth changing in the first place. This is how we've always done compat packages. Go projects version import paths (e.g. github.com/containerd/btrfs/v2) and we replace / in import paths with -. We can document this in the Go Packaging Guidelines. We have more important things to do than renaming a bunch of packages for a second time, and I don't think this change makes sense to begin with.

Problem is:
- I need to request new compat package on fedora-scm-requests
- @tibbs won't approve package with -version anymore
- thus if i want the package approved, i need to rewrite the goname computation

We cannot change this without breaking many packages

Package won't be broken because they will be superseeded by the replacement with Provides/Obsoletes.
Packages will be retired in Rawhide
Stable branches won't be buildable anymore, but there won't be any reason to rebuld a retire package.

• @tibbs won't approve package with -version anymore

That's not exactly how I interpreted that comment. I left https://pagure.io/releng/fedora-scm-requests/issue/55886#comment-875403.

Is rather document the -N format for compat packages in the Packaging Guidelines than make hundreds of Go packages break

Yes, I never said I wouldn't approve them.

I have no idea why every Go package decided to do something different; I think the guideline has been in place since before Go packages started entering the distribution, but maybe there's a reason why Go can't follow it. I don't know. I would assume some thought was put into the naming, or maybe the Go guidelines already document that the scheme for those packages is different. (I haven't read them.)

If there is no good reason for the difference then it would be nice if Go packages conformed to the same naming guidelines as other packages, but it may just be that "changing things now is a massive pain" qualifies as a good reason. If so, someone should simply take that to the packaging committee, explain what has happened, and send a PR for the Go and naming guidelines describing the scheme. (The latter has sections at the end describing issues for specific languages/ecosystems.)

https://pagure.io/packaging-committee/issue/1307