Re: packaging go-ethereum, and ultimately bee (of ethswarm.org)

[Sarah Morgensen <iskarian@mgsn.dev>]

Hi,

Maxime Devos <maximedevos@telenet.be> writes:

>> > have uses outside go-ethereum, so they can be re-used as dependencies of
>> > new go packages, so over time, having to define many new packages when importing
>> > a go application should become less and less of a problem.
>> > 
>> > (About version pinning: I'm ignoring version incompatibilities here. I don't know
>> > how much of a problem that is in practice ...)
>> 
>> i'm not a go expert at all, but i think it's a rather frequent
>> situation in go land to move a dependency one git commit ahead, only
>> to pick up a bugfix that has just been pushed into its repo.
>
> ... unless you meant this here?  But this seems to imply that version
> incompatibilities typically don't happen (otherwise just picking up
> a bugfix with a single commit doesn't seem plausible), so we can
> typically just use the latest version of the go module in guix, no?

A clarification: a canonical Go module version is supposed to follow
semantic versioning guidelines [0], so anything except a major version
bump is supposed to be backwards-compatible.  This is further supported
by major version suffixes [1], which requires that "[s]tarting with
major version 2, module paths must have a major version suffix like /v2
that maches the major version.  For example, if a module has the path
example.com/mod at v1.0.0, it must have the path example.com/mod/v2 at
version v2.0.0."  Because each Guix package only represents one module
path, and that module path is used in the name of the package, we
*should* be able to update to (and use) any newer minor versions of a
module with no issues.

This doesn't address packages without any canonical versions, of
course...

[0] https://golang.org/ref/mod#versions
[1] https://golang.org/ref/mod#major-version-suffixes

--
Sarah