It's funny. I was discussing looking into packaging kubernetes with another Arch developer yesterday, and noticed this discussion today. I'm the package mainta

It's funny. I was discussing looking into packaging kubernetes with another Arch developer yesterday, and noticed this discussion today. I'm the package maintainer for go and maintain a number of go packages in Arch Linux, along with writing the current guidelines and looking into packaging strategies for golang. I'll offer a more cynic view then the one presented: golang is not a mature packaging ecosystem. So 1) is partially correct; go just sucks from a packaging perspective. Not really the issue at kubernetes. We can probably package up kubernetes within the next hour and drop it into `[community]` as Arch has less structure and QA around the packaging process. However our largest hurdle is that we package the latest version. Is kubernetes going to work properly on go version `1.15.3`. By experience container software brings out the worst of the go runtime and any changes to the syscall, goroutine or memory management is a cause of concern. The other hurdle is the cadence of when kubernetes decides to support which container runtime. Docker is wonkey at best, but I haven't seen a lot of details on cri-o nor containerd. So frankly our problems are not really related to packaging, but the challenges of providing recent versions of packages and making sure they work.