Packaging of Go modules

[Olivier Lemasle]

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

[Nicolas Mailhot]

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,

[Robert-André Mauchin]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> g