Hi all,
I have two questions related to the packaging of Go modules.
1. When a new major version of a Go module is released, breaking backwards compatibility, the module path should be changed [1]. According to the Golang Packaging Guidelines, it means updating the goipath and renaming the package, right? goaltipaths is then set to the old import path, right?
Looking for examples of Go packages with such a transition, I found the opposite: for example gotest.tools was updated to gotest.tools/v3, but Fedora package golang-gotest [2] has the following in spec:
%global goipath gotest.tools %global goaltipaths gotest.tools/v3
Shouldn't it be the opposite? Is it required for all Go Fedora packages to be renamed when a new major version is released? It will cause quite a burden if this require a review request for every upgrade.
2. What should be done for multi-module repositories [3]? These repositories contain multiple Go modules (each one with its go.mod); git tags are created for each module (with the form path/version).
An example of such a multi-modules repository is https://github.com/moby/sys, which contains 3 modules; - github.com/moby/sys/mount - github.com/moby/sys/mountinfo - github.com/moby/sys/symlink
Tags are created for each module [4]; each module has a different version. Current Fedora package golang-github-moby-sys [5] package it like any other Go package, but tags do not follow monotonically increasing versions.
I suppose it could be possible to version such a package as if there was no tagged release (so Version: 0, and git hash in release number). But it seems perhaps more logical to have a Fedora package for each Go module in the repository, as a project may depend on each module with a different version...
Thanks,
-- Olivier Lemasle FAS: olem
[1] https://blog.golang.org/v2-go-modules [2] https://src.fedoraproject.org/rpms/golang-gotest [3] https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories [4] https://github.com/moby/sys/tags [5] https://src.fedoraproject.org/rpms/golang-github-moby-sys
Hi Olivier,
You are very right, and all this has been rewritten and fixed in my devel branch. Unfortunately the F33 change process ate all the time I had to spend on the subject on the summer, and now personal problems and covid consequences are preventing me from finishing things.
You can see a working POC here https://copr.fedorainfracloud.org/coprs/nim/go-modules/packages/
(at the time I also successfully tested multi-module packaging with different versions from a single spec)
If you have some cycles to spend on the subject you can try to un-stick
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/109
because I don’t have the time right now to beg people to look at it again. Besides after months of the same unchanged code sitting in the review queue I’m franckly sick of it all
Regards,
On Monday, 2 November 2020 22:45:09 CET Olivier Lemasle wrote:
Hi all,
I have two questions related to the packaging of Go modules.
- When a new major version of a Go module is released, breaking backwards
compatibility, the module path should be changed [1]. According to the Golang Packaging Guidelines, it means updating the goipath and renaming the package, right? goaltipaths is then set to the old import path, right?
Looking for examples of Go packages with such a transition, I found the opposite: for example gotest.tools was updated to gotest.tools/v3, but Fedora package golang-gotest [2] has the following in spec:
%global goipath gotest.tools %global goaltipaths gotest.tools/v3
Shouldn't it be the opposite?
Yeah, but that imply to redo a review with a rename
Is it required for all Go Fedora packages to be renamed when a new major version is released? It will cause quite a burden if this require a review request for every upgrade.
For the new package probably yes. For existing package, you could have the current package bumped to the latest version, and do a compat package for old versions if necessary.
- What should be done for multi-module repositories [3]?
These repositories contain multiple Go modules (each one with its go.mod); git
tags are created for each module (with the form path/version).
An example of such a multi-modules repository is https://github.com/moby/sys,
which contains 3 modules;
- github.com/moby/sys/mount
- github.com/moby/sys/mountinfo
- github.com/moby/sys/symlink
For now we don't handle modules. So package the top repo? I'd like nim advice on this though.
Tags are created for each module [4]; each module has a different version. Current Fedora package golang-github-moby-sys [5] package it like any other Go package, but tags do not follow monotonically increasing versions. I suppose it could be possible to version such a package as if there was no tagged release (so Version: 0, and git hash in release number). But it seems perhaps more logical to have a Fedora package for each Go module
in the repository, as a project may depend on each module with a
different version...
Thanks,
-- Olivier Lemasle FAS: olem
[1] https://blog.golang.org/v2-go-modules [2] https://src.fedoraproject.org/rpms/golang-gotest [3] https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories [4] https://github.com/moby/sys/tags [5] https://src.fedoraproject.org/rpms/golang-github-moby-sys _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.or g
golang@lists.fedoraproject.org