The Debian tech committee allows Kubernetes vendoring [LWN.net]

Back in October, LWN looked at a conversation within the Debian project regarding whether it was permissible to ship Kubernetes bundled with some 200 dependencies. The Debian technical committee has finally come to a conclusion on this matter: this bundling is acceptable and the maintainer will not be required to make changes:

Our consensus is that Kubernetes ought to be considered special in the same way that Firefox is considered special -- we treat the package differently from most other source packages because (i) it is very large and complex, and (ii) upstream has significantly more resources to keep all those moving parts up-to-date than Debian does.

In the end, allowing this vendoring seemed like the only feasible way to package Kubernetes for Debian.

to post comments

The Debian tech committee allows Kubernetes vendoring

Posted Jan 21, 2021 20:06 UTC (Thu) by walex (guest, #69836) [Link] (4 responses)

«upstream has significantly more resources to keep all those moving parts up-to-date than Debian does.»

"Vendoring" programs into "apps" is the very purpose of popular choices like containers and "thin" VMs, and that is usually justified with the "upstream has significantly more resources" story, that is developers have more time to keep an "app" updated.

That works as long as it works, that is as long as "upstream" is willing to fully maintain both the program and all its dependencies that make up the whole "app". But my experience is that rarely this happens over the medium-long period, and eventually "apps" become abandonware.

Now that applies in particular to versions of an app, and indeed most distros with Firefox just constantly update it even if they are supposed to be "stable" distros. For Firefox there is the ESR "stable" version, but I wonder how many production "apps" in their vendored bundles or containers or VMs do have ESR-like "stable" versions.

Note that I am not blaming distros here for eventually giving up and adopting the vendored bundle approach and thus eventually creating abandonware: that is the result of the developers adopting the "dump into the trunk whatever mess" approach to "engineering" their "apps".

The Debian tech committee allows Kubernetes vendoring

Posted Jan 21, 2021 22:57 UTC (Thu) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

True

Yet, abandonware already exists on Debian, in form of an orphan package
From a release to another, if the package has too many bugs, it gets dropped and the story ends

Meanwhile, Debian users have access to the software

The Debian tech committee allows Kubernetes vendoring

Posted Jan 22, 2021 20:01 UTC (Fri) by walex (guest, #69836) [Link]

Packages get abandoned by DDs, but not before the long-term support of a Debian release ends. Also at least usually most if not all their dependencies are in other non-abandoned Debian packages, so at least those get still maintained.

The big issue with "vendoring" and programs turned into bundles like "apps" is that once they get abandoned, both the program and its dependencies stop being maintained, and the bundle/container/VM in which they are packaged rots as a whole.

The Debian tech committee allows Kubernetes vendoring

Posted Jan 22, 2021 2:15 UTC (Fri) by khim (subscriber, #9252) [Link]

I wonder how many production "apps" in their vendored bundles or containers or VMs do have ESR-like "stable" versions.

One example I have already showed: Jenkins considers about three months a “Long Term Support” (I'm not joking).

The Debian tech committee allows Kubernetes vendoring

Posted Jan 23, 2021 3:01 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

The (broader) problem is that there is frequently no incentive for upstreams to make distributors' lives easy in this regard.

This is particularly blatant with k8s, where the primary goal is to serve as an on-ramp to GCP and AWS, not to be installed on a "regular Linux box." Both GCP and AWS provide managed solutions that (probably) don't involve Debian or a similar user-facing distribution at all. From the perspective of k8s upstream, the main (most important, not necessarily largest) group of people who want to install k8s on a regular Linux box are developers (*not* sysadmins), and developers generally want to have the latest and greatest version (or at least a version which is reasonably similar to whatever GCP and AWS are using). AWS and GCP, in turn, have their own idea of what counts as a "stable release" which tends to be very different to that of the outside world, primarily because they both have large SRE teams whose entire job is to make unstable software perform reliably (enough) at scale.

Anyway. k8s wants to make it easy for developers to get the AWS/GCP version, and there are two obvious ways of doing that:

1. Provide tarball/binary downloads and/or custom APT/RPM repositories. Upload new things on whatever schedule strikes their fancy. Vendor *everything* since the user probably has older libraries. Debian is then presented with the Hobson's choice of accepting it as-is, meticulously un-vendoring everything and testing that it all still works correctly, or not having a k8s package.
2. Cooperate with Debian et al. and provide stable packages which may be months or years old. Then tell developers to switch to the testing or unstable track just for that one package. This will drag in half a dozen library dependencies from testing/unstable, and might also force the updating of other packages which depend on those. But Debian gets to have its nice un-vendored k8s package.

#1 is low-friction for end users, while #2 is high-friction.

The Debian tech committee allows Kubernetes vendoring

Posted Jan 22, 2021 12:45 UTC (Fri) by amarao (guest, #87073) [Link] (1 responses)

I truly appreciate tech. committee response. It's well though and provides a good reasoning.

The Debian tech committee allows Kubernetes vendoring

Posted Jan 22, 2021 19:24 UTC (Fri) by jezuch (subscriber, #52988) [Link]

I'm always looking forward to reading their resolutions. It's like a breath of a fresh common sense in this crazy world ;)

The Debian tech committee allows Kubernetes vendoring

Posted Jan 22, 2021 18:32 UTC (Fri) by jccleaver (guest, #127418) [Link] (2 responses)

I realize k8s is complex, but it's not *so complex* that it can't be rewritten a language ecosystem more amenable to properly-separated development.

If something reliably provided the 80% most used features of k8s and was written in either C or a scripting language I think there'd be an OSS market for it for sure.

The Debian tech committee allows Kubernetes vendoring

Posted Jan 22, 2021 18:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

You can try, it would cost just a dozen million USD in manpower. All to make it easier packageable in Debian.

The Debian tech committee allows Kubernetes vendoring

Posted Jan 25, 2021 13:17 UTC (Mon) by marduk (guest, #3831) [Link]

> If something reliably provided the 80% most used features of k8s and was written in either C or a
> scripting language I think there'd be an OSS market for it for sure.

Do you mean like OpenStack?