LXD Packaging Report, Wild West edition

Well, I’m calling this the “Wild West” edition of my LXD packaging report, as I have been reminded once again how crazy golang package development is. A few examples that have made me particularly sad this past week:

• Repositories that are a fork-of-a-fork-of-a-fork….. The vast majority of golang packages live on GitHub, which encourages people to fork repos left and right. The downside is that people will make a small change, and never bother to try to merge it back to the parent repository. You then have people making forks from the child repositories, and it becomes a coin toss which “generation” of a library will actually be picked and used. You also end up with a very high noise-to-signal ratio with tons of similarly named (and probably identical) packages when you are trying to search for something.

• Projects pin to an arbitrary commit, and then never update that dependency. I’ve encountered libraries that are using multiple different versions of the same dependency, which just serves to bloat the dependency tree for a project.

• Speaking of dependencies – “A release? What’s that?” Half of the libraries I’ve dealt with so far have never actually tagged a proper release. Just throw more commits at it – that should be fine, right?

• invalid flag in #cgo CFLAGS, or, “Whatever could go wrong with downloading and running untrusted, random code from the Internet?” I’ve encountered this before, but forgot just how much facepalming this induces… have fun reading the wiki page if you want.

• The absolute stupidity that is protobuf v1 and v2 within the golang ecosystem. I’m at a loss of words for how poorly the new, v2 release of the protobuf library was handled. I’ll just quote the go.dev blog post announcement and trust it induces the proper wailing and gnashing of teeth:

  Why start at version v1.20.0? To provide clarity. We do not anticipate APIv1 to ever reach v1.20.0, so the version number alone should be enough to unambiguously differentiate between APIv1 and APIv2.

  Gee, if only there was some major version number you could have used to indicate a new, major API that’s not backwards-compatible with the previous v1 API. If only there was some semantically-informative way that they could have conveyed that information. Well, I guess calling v2 “20” and putting it in a minor location within the version string will make perfect sense to everyone else.

OK, enough complaining about golang…. on to the packaging update for the past week!

NEW/updated packages accepted into unstable:

• golang-github-digitalocean-go-smbios
• golang-github-flosch-pongo2.v4
• golang-github-go-macaroon-bakery-macaroonpb
• golang-github-jaypipes-pcidb
• golang-github-jkeiser-iter
• golang-github-juju-clock
• golang-github-juju-collections
• golang-github-juju-errors
• golang-github-juju-gnuflag
• golang-github-juju-mutex
• golang-github-juju-persistent-cookiejar
• golang-github-juju-qthttptest
• golang-github-juju-schema
• golang-github-juju-testing
• golang-github-juju-usso
• golang-github-juju-version
• golang-github-juju-webbrowser
• golang-github-mdlayher-netx
• golang-github-x448-float16
• golang-gopkg-httprequest.v1
• golang-gopkg-juju-environschema.v1
• golang-gopkg-macaroon.v2

NEW packages pending upload:

• golang-github-juju-aclstore
• golang-github-juju-names
• golang-github-juju-simplekv
• golang-github-mhilton-openid
• golang-gopkg-goose.v1
• golang-gopkg-macaroon-bakery.v2

Pending updates to existing packages:

• golang-github-canonical-go-dqlite
• golang-github-go-ldap-ldap
• golang-github-yohcop-openid-go
• golang-gopkg-lxc-go-lxc.v2
• golang-gopkg-retry.v1
• golang-petname

As before, thanks to Aloïs Micard for continued feedback and sponsoring my changes. Also, thanks to Shengjing Zhu and Pirate Praveen for helping me understand the mess that is the golang protobuf library transition.