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. > > 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?
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. > 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 > 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-le...@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/gol...@lists.fedoraproject.or > g _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-le...@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.org
