Bug#971515: Status as of last tech-ctte meeting
This is an excellent discussion and a good summary. Thank you, Gunnar!
Gunnar Wolf <gwolf@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: