5:21 a.m.
On Monday, 2 November 2020 22:45:09 CET Olivier Lemasle wrote:
For now we don't handle modules. So package the top repo?
I'd like nim advice on this though.
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)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
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
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...