On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote: > 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. [...] > 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.
This is an excellent summary of the issue, tensions, and values involved. Thank you, Russ; you continue to be a major voice of clarity, even-handedness, and genuine considerate deliberation. In particular, I think you've captured the key values that are in tension here, and the tradeoffs that Debian faces. As you said, it's hard for us to re-evaluate things that have been deeply ingrained and feel like core values. Some of the biggest problems Debian has faced involve tension between multiple values, and those are precisely the problems that grow most bitter and challenge our ability to genuinely change our minds. Many people treat "these are my/our values" as the *end* of a discussion, rather than the point at which the discussion has a chance of making major progress. I've encountered this same tension and tradeoff (vendoring vs not vendoring) in various contexts, and worked in ecosystems at different points on that spectrum. Your message gives me a great deal of hope and optimism for how Debian may tackle this problem. In particular, with my upstream Rust/Cargo hats on, I would love to work with you and others on questions of what software packaging could look like, and how to maintain the quality and curation *and* package availability of Debian in collaboration with other ecosystems of package and dependency management. Other potentially interesting questions: what are the assumptions that go into our current tradeoffs about shared libraries vs static libraries, and are those still the correct tradeoffs in all cases? Josh Triplett
