3 ms·
> There's another interpretation available: kubernetes is not a mature system, and that's why it's too much work to package properly. If that were true, one wo
by jancsika 6y ago
> There's another interpretation available: kubernetes is not a mature system, and that's why it's too much work to package properly.
If that were true, one would expect the packagers at Arch to be leveling similar complaints about the "maturity" of the software or the "awful" build system used by Kubernetes.
I'm going to rankly speculate that:
1. That is not the case.
2. Kubernetes was packaged in Arch in less time than it's taken for Debian to discuss the policy disagreement between the previous and current package maintainers, neither of which have been able to deliver a maintainable Kubernetes package in Debian yet.
3. This says more about the efficacy of Debian's packaging policies and package dev UX than it does about Kubernetes.
- jancsika 6y agoAlso-- I'm willing to bet there are similar charges somewhere in a Debian discussion list wrt Virtualbox and its packaging. And I'm willing to bet that there's currently a virtualbox package in Arch and little to no discussion about how "unstable" or whatever virtualbox is.
- Foxboron 6y agoIt'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.