This is an excellent discussion and a good summary. Thank you, Gunnar! Gunnar Wolf <gw...@gwolf.org> writes:
> There is a course of action that's unlikely to leave everybody happy, > but is worth considering: Phil said: > Phil> > that makes it seem like what we actually need is a decent way of > letting our users install the upstream binaries, rather than > trying to force those packages into Debian as a special case > Sean agreed with him; probably something as K8S due to its nature is > not suited for Debian inclusion (but we'd still have to ensure it's > easy to build and install, not from packages). But the quesion is > where to draw the line: I want to explicitly state my concern with this approach, speaking as one of a community that I think may have been a bit underrepresented in this discussion to date: a user of the kubernetes-client package in Debian. There are a lot of fascinating edge cases and precedents and philosophical questions about the function of a distribution here, and I think they rightfully attract a lot of energy, but I'm worried this is at the cost of losing sight of the core functionality provided by Debian. Because that functionality is currently working, the people who are benefiting from it don't know to weigh in. I maintain a bunch of Kubernetes clusters as part of my job. Those clusters are run by other people (cloud providers, data centers, etc.). I need clients to talk to those clusters. When I first started working with Kubernetes, I realized I needed a client, worried about how much of a pain that would be, did an apt-cache search for kubernetes, found kubernetes-client, breathed a sigh of relief, and ran apt install kubernetes-client. I have subsequently not given Kubernetes clients a second thought. Not having to think about things like that is exactly the point of Debian. It's possibly the highest standard of success for a distribution. By comparison, I also use Helm and Argo CD as part of my job. Helm has a snap package that's kind of maintained and sort of works but kept being irritating plus I had to remember to upgrade a different thing. Argo CD is available only as a binary download from its release page and therefore I never remember to upgrade it and run into weird problems and then have to go download new versions. The experience is annoying and irritating and reminds me of when my primary working system was running Solaris. As a Debian developer, I appreciate the arguments about vendoring and the desire to maintain Go libraries and the pride that we take in our work of really understanding software and packaging it properly. However, as a Debian *user* of the kubernetes-client, I have to say that I do not care in the slightest. The older, unvendored kubernetes-client package worked great. The new, heavily vendored kubernetes-client package works great. Both do exactly what I want, and I don't care at all, as a user, which is in Debian. But if the package were removed from Debian, I would be really unhappy. And if Helm and Argo CD were packaged for Debian, I would be much happier, so if unvendoring them is the obstacle, as a user I'm opposed to unvendoring! I want to push back a bit against the feeling that some things are ill-suited for how Debian has historically packaged software and therefore maybe Debian isn't the place for them, and we should instead ask people to manage them outside of Debian (but somehow make this easy). First, while I appreciate and cheer Phil and Sean's optimism, there have been a lot of plans in Debian historically to make something that isn't a package easy to build and install, and they have basically never worked. The way Debian makes something easy to build and install is by making it a package. That's what our entire project is designed around, and I'm dubious that we're going to be able to reproduce those properties with something that isn't a package. Second, the point of Debian at the end of the day is that I can install it on a computer and use it to get things done. The details we're discussing here are important and work towards making Debian maintainable and sustainable and to ensure that a quality bar has been met in terms of security and legality and licensing, but I think it's important that they are also means to an end and the end is not security and licensing per se. We're not making a random collection of relatively secure software; we're giving people programs that they can run while keeping them secure. We're not just a classification system for what software is free; we're giving people software they can use while ensuring that all of it is free. I think it's worth occasionally stepping back and dwelling on that thought for a moment and making sure we're picking the right strategy for meeting our quality bar that allows us to still achieve the mission. This is particularly true for something like vendoring or the avoidance of vendoring, which is not a core mission. It's not in the social contract, and it's not a DFSG principle. It's a hard-won and very valuable piece of experience with how best to sustainably make a distribution... but one that was hard-won in the era of C programs and shared libraries and that has generalized admirably to Perl and Python. It may generalize to other languages and other mechanisms for distributing software. It may not! If it doesn't, that's significant because it's such a deeply-engrained part of our culture, but it's *not* a breach of our fundamental project goals. We can consider new approaches here without becoming untethered, and indeed may be able to achieve our primary goal *better* by expanding the scope of software that we can include in the distribution and that can therefore just work. I think there's a bit of a crisis of confidence in Debian because of how much larger the free software ecosystem is now than it was when the project started, how far away from doing everything through a distribution a lot of developers have moved, and how many resources are flooding into other areas that we have difficulty keeping pace with. One of the natural reactions to that crisis of confidence is to pull back from these new and difficult and unfamiliar areas and decrease scope to the things we know we're really good at: packaging primarily C, C++, Perl, and Python code. And that is a valid strategy; it's okay to just keep being very good at something one is already very good at. But I think in the long term that means Debian becomes something much different than it historically has been. It means Debian would become a base on which other people would build things, rather than a comprehensive collection of tools that covers all the incidental things you need from a computer, and where people need only reach outside of Debian for the thing on which they're doing primary development and thus need the bleeding edge and the flexibility of using unreleased or unpackaged code. I think it's going to be challenging for Debian to continue to be that universal toolbox, but I also think it's exciting and valuable. I still want to try to achieve it, and I would rather adopt new strategies for packaging that make life simpler and easier for packagers and allow us to keep pace with more upstream packages than to reduce scope to only the things we already know we're good at. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>