Golang Xen packages and the golang packaging system

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

So currently, our build system will install the xenlight package into 
$PREFIX/share/gocode/src/golang.xenproject.org/xenlight.  However, it actually 
takes a bit of wrestling to get golang to use this location, and makes it 
difficult to use shared code.  It would be nice if people could simply add 
`golang.xenproject.org/xenlight` to their dependencies, and have `go get` just 
DTRT.

This basically involves two things:

1. Creating a publicly-accessible suitable git repo containing the golang 
package(s)

2. Causing `curl golang.xenproject.org/$PKGNAME` to return some HTML with the 
following rune:

<meta name="go-import" content=“golang.xenproject.org git $URL”>

Where $URL points to the tree from #1.

We should probably also have some more human-friendly content in case someone 
wanders there with a web browser.

“Suitable git tree” means:
- That it contains just the bindings.  
- Any ‘released’ Xen version has a tag of the vA.B.C format

I think ideally we’d like the ‘master’ branch of this git tree to contain the 
bindings from the xenbits.xenproject.org/xen.git master branch, but that’s 
somewhat negotiable.

So what we’d need to do is have a process / hook somewhere which would, on push 
to xenbits.xenproject.org/xen.git ’s master branch:
 - Generate the bindings from the source code
 - Copy these bindings into the git repo, replacing the old bindings entirely 
(i.e., deleting files which don’t exist any more, adding new files)
 - Running ‘git commit’, probably with information about the commit from which 
this code has been generated
 - Check to see if there is a new RELEASE-X.Y.Z tag and generate an appropriate 
tag
 - Push to the git repo in step #1 above

This script should live in xen.git I guess.

I guess maybe it would make sense to have one git tree per package, and put 
them at xenbits.xenproject.org/golang/$PKGNAME? (e.g., 
xenbits.xenproject.org/golang/xenlight.git?)  At any rate, something that would 
allow us to leverage our current githttp instance on xenbits.

One question I have from the above is how the xen.git RELEASE-X.Y.Z should 
correspond to the vA.B.C in the golang package repo.

The obvious answer, of course, is (A, B, C) = (X, Y, Z); that is, xen.git tag 
RELEASE-4.14.0 should create a golang package tag of v4.14.0.

The issue with this is that golang assumes you’re using semantic versioning; so 
a `go get -u` would normally feel justified in upgrading from v4.14.x to 
v4.15.x.

A couple of possible responses:

1. Declare that OK.  That would mean not only that we have to have v4.15.x be 
compatible with golang source code written against v4.14; it would also mean 
that v4.15.x needs to be able to *compile* against libxl version 4.14.  Which 
might be a good idea, but we’d want to think carefully before making that kind 
of commitment.

2. Declare that people need to use `go get -u=patch` when updating, and/or use 
go.mod &c to manually restrict the version of go to use to the 
currently-installed Xen version

3. Map (A, B, C) = (Y, Z, 0).  (i.e., RELEASE-4.14.5 would make tag v14.5.0 .)  
`go get` wouldn’t update automatically, but it might be confusing which version 
*should* be used; particularly if we ever roll over a major version for Xen.

Any other possibilities?

I think I’d start out with #2, and then consider moving to #1 at some point in 
the future.

Thoughts?

 -George