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
