[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Golang Xen packages and the golang packaging system

  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Wed, 22 Apr 2020 16:04:37 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=George.Dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Ian Jackson <Ian.Jackson@xxxxxxxxxx>, Nick Rosbrook <rosbrookn@xxxxxxxxx>
  • Delivery-date: Wed, 22 Apr 2020 16:04:50 +0000
  • Ironport-sdr: UNylRPrAYfP3GfQSrhbLHR7RfLs8sVNQca8ZWW74vZSHRaQunXFZ9KQD06h2FWe2feNXNl9Qn3 bNenCEKN216GJzlswJowevaxbHQlqCNYiQAUUkOQeX/C+okB149M7tYbIbmBvOjTuPvTXyhCrS iZ5pmG3pH3LfeaPQrIu4cXWBI5UVtjBjFWzWk4t2Akda6Kl49YDqQuY5mTWRaj+jzDJ1LraKn2 JOvof84gqSQLwRrwHOK7vMqn0nUd0EwCvB9e1psBcx7Jq5uSNKwhf+EJDu3RuNc0faAi5WJ2v/ d70=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWGL+4RaHBeS8dkEGvpDIRZjts4w==
  • Thread-topic: Golang Xen packages and the golang packaging system

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 

This basically involves two things:

1. Creating a publicly-accessible suitable git repo containing the golang 

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 
 - 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 

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.





Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.