PR#55: Fix goname generation to match versioning guildelines - go-rpm-macros

go-rpm-macros

#55 Fix goname generation to match versioning guildelines

Closed 2 years ago by eclipseo. Opened 2 years ago by eclipseo.

eclipseo/go-rpm-macros fix_goname into master

Fix goname generation to match versioning guildelines

Robert-André Mauchin • 2 years ago

c955863

rpm/lua/srpm/go.lua

file modified

+13

		`@@ -69,6 +69,19 @@`
		`-- numbers on top of it, keep a - prefix before version strings`
		`result = string.gsub(result, "%-v([%.%d]+)$", "-%1")`
		`result = string.gsub(result, "%-v([%.%d]+%-)", "-%1")`
		`+ -- according to the guidelines, if the base package name does not end with`
		`+ -- a digit, the version MUST be directly appended to the package name with`
		`+ -- no intervening separator.`
		`+ -- If the base package name ends with a digit, a single underscore (_) MUST`
		`+ -- be appended to the name, and the version MUST be appended to that, in`
		`+ -- order to avoid confusion over where the name ends and the version begins.`
		`+ result = string.gsub(result, "([^-]*)(%-?)([%.%d]+)$", function(prior, hyphen, version)`
		`+ if string.find(prior, "%d$") then`
		`+ return prior .. "_" .. version`
		`+ else`
		`+ return prior .. version`
		`+ end`
		`+ end)`
		`return(result)`
		`end`

eclipseo commented 2 years ago

The package version, which SHOULD include the periods present in the original
version.

If the base package name ends with a digit, a single underscore (_) MUST be
appended to the name, and the version MUST be appended to that, in order to
avoid confusion over where the name ends and the version begins.
If the base package name does not end with a digit, the version MUST be
directly appended to the package name with no intervening separator.

Fix https://pagure.io/GoSIG/go-sig/issue/53

decathorpe commented 2 years ago

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

eclipseo commented 2 years ago

Testing is in progress.

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

gotmax23 commented 2 years ago

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.

eclipseo commented 2 years ago

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

eclipseo commented 2 years ago

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.

gotmax23 commented 2 years ago

@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.

decathorpe commented 2 years ago

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

tibbs commented 2 years ago

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.)

eclipseo commented 2 years ago

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

Pull-Request has been closed by eclipseo

2 years ago