Packaging Kubernetes for Debian

Posted Oct 30, 2020 21:35 UTC (Fri) by khim (subscriber, #9252)
Parent article: Packaging Kubernetes for Debian

The whole thing boils down to one simple fact: Linux distributions are not really an operations systems.

What is an operation system? Well, Wikipedia says it's system software that manages computer hardware, software resources, and provides common services for computer programs… and Linux distributions are not doing that.

There are no SDK, there are no ability for the developer of a computer program to deliver it's application to users… not even Apple (which is known for it's strict and heavy handling of developers) demand to cede that much control.

And, that super-brand-new “software developed in the 2020s”… is not any different from Turbo Pascal or MS Office developed quarter-century ago.

The only difference: today open source have become popular enough for the software that what was traditionally proprietary is now open-sourced. You can find source on GitHub or maybe some other such site. But that's it. It's developers are not embracing ideals of free software and are not looking for a way to integrate with distributions.

On the contrary: they just seek a way to deliver their goods to users.

Maybe it's time to accept ad acknowledge that and stop trying to pull all these packages into the distribution? But provide a way to install upstream versions? Something like these "Shops" other OSes have?

Why does Kubernetes even have to be in Debian? What's the end goal? What this “packaging” which is just putting piece of software without any attempt to alter it is supposed to achieve?

Packaging Kubernetes for Debian

Posted Oct 30, 2020 23:06 UTC (Fri) by pollo (subscriber, #122775) [Link] (12 responses)

> Why does Kubernetes even have to be in Debian? What's the end goal? What this “packaging” which is just putting piece of software without any attempt to alter it is supposed to achieve?

It provides:

* security -- Debian developers are supposed to read an review the code they package
* convenience -- a single package manager for all the software on your system, automated updates, etc.
* stability -- Debian developers work hard to try to make Debian a cohesive environment

As a sysadmin, I can tell you all of this has a lot of value.

Oh, and it's false to say Debian developers don't alter software. They often write patches to fix specific problems and most of the time these patches end up being merged upstream.

Packaging Kubernetes for Debian

Posted Oct 30, 2020 23:42 UTC (Fri) by Wol (subscriber, #4433) [Link] (9 responses)

But this is placing Debian Developers on a pedestal.

At the end of the day, do the users care? Do the *users* trust Debian, or do they trust Kubernetes, and which do they trust more?

If the *users* are simply using Debian as a platform to run Kubernetes, then all these "advantages" are pretty irrelevant - all the users need is for Kubernetes to install and run successfully. Which is best achieved by Debian and Kubernetes working together with, hopefully, a couple of primarily Kubernetes devs also being Debian Developers tasked with making Debian a good platform to run Kubernetes on.

Yes I know Debian (or any other distro) needs to make sure all these big apps run successfully on Debian, but if they've got plenty of developers you're better off working with said devs to make sure the package installs successfully on Debian, rather than expending a lot of resources you haven't really got to make the package actually part of Debian.

Cheers,
Wol

Packaging Kubernetes for Debian

Posted Oct 31, 2020 0:58 UTC (Sat) by dskoll (subscriber, #1630) [Link] (8 responses)

I certainly prefer my software to be packaged by Debian, or at least as .debs with a public repo. If we're talking one or a handful of machines, it's no big deal. But if you administer hundreds or thousands of machines, using the package manager to handle updates is hugely worthwhile.

I have a lot of trust that Debian upgrades won't break my system; this trust is in place because historically, very few Debian upgrades have been problematic. Having the Debian maintainers develop and test updates, that I can then confidently and easily deploy to many machines, is fantastic.

Back when I ran a software company, we put in the effort to make .debs and .rpms of our software (it was proprietary software, so would never be packaged by a Linux distro.) But making the effort to adapt our software to the distros we supported was very beneficial because it made our upgrades very easy.

Unfortunately, few upstream developers are willing to put in the time to make .debs, leaving that task to Debian maintainers.

Packaging Kubernetes for Debian

Posted Nov 1, 2020 12:15 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

Having one repository with all the relevant applications is nice, I agree. But you don't need to build and package these by one central team. “Shops” which I mentioned work just fine for that.

As for “upstream developers” unwillingness to create .debs… nothing have changed there in last quarter-century. “Upstream developers” want to build one package and distribute one package.

Anything else just doesn't make any sense from support POV.

If Linux distributions are unwilling to provide a way for that to happen… developers would cobble together some kind of .sh script. Or some kind of installer. Or would solve problem in some other way.

Some solutions would even provide .debs or .rpms — but they would use the same binaries as “main” tar or sh.

And yes, I agree: it's false to say Debian developers don't alter software… but then situation is even worse: now developers need to deal not just with some unfamiliar (to them) environment, they even have to support code which they haven't wrote and don't even know about! No wonder that makes them unhappy.

Packaging Kubernetes for Debian

Posted Nov 1, 2020 15:18 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] (5 responses)

“Shops” which I mentioned work just fine for that.

Shops work OK at putting all the software in one place in an easy to install format. Experience says they do a very poor job of quality control and security updating, at least without effort on the part of the shopkeeper on par with what distributions currently spend on packaging. Even shops run by big companies like Apple and Google can't keep out all the malware and just plain insecure software.

IMO, this is the point that gets ignored by in these discussions: the biggest effort distributions spend is not really in packaging, it's in various forms of quality control. It may make sense to skip some of that quality control for the biggest, best maintained packages, like web browsers and databases, which are backed by the kind of big commercial team that can spend more effort on QA/QC than the distro can, but it won't work so well to skip that effort for smaller packages that can't.

Packaging Kubernetes for Debian

Posted Nov 10, 2020 11:04 UTC (Tue) by anton (subscriber, #25547) [Link] (4 responses)

For some packages, the contribution by Debian is negative. E.g., for many years now, I have needed to build xpdf from source on every Debian/Ubuntu system because the Debian-crippled version only prints on letter paper (which we don't have around here); all configuration options for A4 paper (both the upstream xpdf ones as well as the Debian ones) are ignored.

Maybe the overall contribution by Debian is positive, but it seems to me that some Debian people are too convinced of their importance, and would do better by just packaging the upstream with as few changes as possible.

Packaging Kubernetes for Debian

Posted Nov 12, 2020 0:18 UTC (Thu) by foom (subscriber, #14868) [Link] (2 responses)

That sounds like it may be a bug indeed; have you reported it?

On the other hand, the upstream version of xpdf inexplicably refuses to let you copy text from certain PDFs, and upstream refuses to fix this. The debian version has fixed that bug.

Packaging Kubernetes for Debian

Posted Nov 12, 2020 9:14 UTC (Thu) by Wol (subscriber, #4433) [Link]

I believe the pdf spec allows you to put flags in saying "you can do this, you can't do that".

I guess Debian honour those flags to avoid potential legal liability. Sounds pretty typical for them.

Cheers,
Wol

Packaging Kubernetes for Debian

Posted Nov 12, 2020 9:55 UTC (Thu) by anton (subscriber, #25547) [Link]

xpdf does not allow to copy text from PDFs that have been marked accordingly, and that was documented (I don't find that documentation at the moment, though). So it's a misfeature, not a bug; however, the documentation explained that it is easy to change xpdf to ignore the flag, so if that's what Debian's maintainers want to do, I don't think they need to ignore all sources of the desired paper size to do it.

Packaging Kubernetes for Debian

Posted Jan 10, 2021 1:32 UTC (Sun) by debacle (subscriber, #7114) [Link]

Is this https://bugs.debian.org/120645 opened 2001-11-22 and closed 2001-11-25?
Maybe you should reopen it, if setting of /etc/papersize to "a4" does not work on your system.
I just tried to print an A4 PDF into a PS file using xpdf 3.04-14 on Debian testing and the result is A4.
Works for me, but that's 19 years later ;-)

Packaging Kubernetes for Debian

Posted Nov 2, 2020 11:48 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

Then it would make sense that if a software can't have that level of quality it should not be packaged.

Packaging it would mean giving false expectations.

I would consider just placing it in contrib so it's not available by default. Maybe even make one of those fake packages that just downloads the binary from upstream, like they do for the microsoft fonts (because there is no license to redistribute them).

Packaging Kubernetes for Debian

Posted Oct 31, 2020 9:17 UTC (Sat) by lobachevsky (subscriber, #121871) [Link]

Sometimes the problems they fix are homegrown, and patches are for integration with the "Debian way" and none of these patches will make it upstream and an ever longer list of patches is dragged around.

systemd is patched quite heavily in Debian and the man pages are not fixed accordingly, so some stuff just silently doesn't work (mostly around localectl). Don't get me started on polkit, which is basically a fork of upstream polkit, because the maintainers just don't like the way polkit is configured since polkit 106.

At some point Debian will have to think about which things it deems absolutely necessary, because changes to upstream software and its own policies that were once sensible will be just dead weight making work on things people actually want to work on harder. There is a danger of newcomers taking their contributions elsewhere (directly upstream or to distros that are closer to upstream) and the project may die a slow death of attrition.

Packaging Kubernetes for Debian

Posted Oct 31, 2020 9:44 UTC (Sat) by ibukanov (subscriber, #3942) [Link]

The argument about the package manager is not relevant here. Many software installs own repositories and use common apt infrastructure for managing updates.

As for security auditing sources for anything sufficiently complex is beyond Debian or any other Linux distribution capabilities. I much more appreciate Debian efforts toward reproducible builds as that allows more people to contribute to auditing.

The stability argument is good one. For example, I appreciate stability that comes from Wordpress packaged in Debian. But I do not see how this is much relevant to vendoring.

Packaging Kubernetes for Debian

Posted Oct 31, 2020 0:49 UTC (Sat) by flussence (guest, #85566) [Link]

> Why does Kubernetes even have to be in Debian? What's the end goal? What this “packaging” which is just putting piece of software without any attempt to alter it is supposed to achieve?

Reduction of curl pipe sudo bash.