Packaging Kubernetes for Debian

Posted Nov 6, 2020 5:46 UTC (Fri) by jccleaver (guest, #127418)
In reply to: Packaging Kubernetes for Debian by cyphar
Parent article: Packaging Kubernetes for Debian

> Note this is not an issue that only affects Go, most modern languages (as well as oldies like Perl and Python) have their own package managers and package ecosystems. When trying to package such programs into a distribution, distributions are kind of stuck. What we have historically done is (in an automated fashion) wrap every language package needed by a project into a corresponding distribution package and hope that there aren't too many to deal with.

I mean, isn't that the crux of the matter? Perl has had CPAN since the days of RH 5, and once cpan2rpm was reliable to use in a mostly-automated fashion it made keeping that in sync for trivial things... trivial. It's only the more involved things that require much manual tweaking, but that's pretty much how it should be since that's why you have humans in the loop to begin with.

Go decided it didn't care, and more to the point the people pushing it decided they didn't care, and now we're stuck.

I can't speak for the Go or rust ecosystem, but I still have difficulty understanding why something like k8s or terraform couldn't be re-implemented in a more traditional language which doesn't force an up-ending of ecosystems that are tried-and-tested.

Packaging Kubernetes for Debian

Posted Nov 6, 2020 5:48 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> I can't speak for the Go or rust ecosystem, but I still have difficulty understanding why something like k8s or terraform couldn't be re-implemented in a more traditional language which doesn't force an up-ending of ecosystems that are tried-and-tested.
Why should somebody bend over backwards to make stuff easier for Linux distros?

Packaging Kubernetes for Debian

Posted Nov 6, 2020 10:44 UTC (Fri) by amacater (subscriber, #790) [Link]

They don't have to, at all - but the big industry players all rely on Linux, even if it's only internally - Google provide a Linux desktop based on Debian testing, for example, if that's what you want for their own staff. There's benefits to having a consistent infrastructure: various languages have done their own thing, an ecosystem or two are now impossible to maintain (gnuradio seems to be an environment which relies on magic, voodoo and blessed builds to keep going :) ). Working with, say, Debian, Ubuntu and CentOS would provide a core that's known.

The comment about security auditing somewhere above in this thread: it's not great, but it's easier in a distribution than a randomly structured ecosystem like NPM / PIP.
Looking from a distance at OpenStack / k8s - there's still a lot of magic, blessed github repositories or whatever around this if you don't go with a single vendor stack (Red Hat/Canonical are effectively vendoring their commercial offerings and depend on you having paid for support).

All of that may be completely immaterial if you're Alphabet/Facebook/AWS and can afford to throw human resources at the relevant language or system for internal use: external use is merely good publicity but you don't have to guarantee users there anything. And yes, I'm coming at this from 25 years of experience with Linux so I may be completely out of touch/too old to appreciate how the real world works.