Bug#971515: CTTE decision on "kubernetes: excessive vendoring (private libraries)"
On Wed, Jan 20, 2021 at 12:28:46PM -0700, Sean Whitton wrote: > 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. > Sigh, You seems to misunderstand why packaging Kubernetes is complex. Package every dependency and using dpkg dependency relationships are possible and easy. Creating a Go package has automated tool, it won't take much time to package all. We can also have more than one version of one library if Kubernetes has particular need. The real complex things are, dealing license and copyright and *NEW* queue. If this TC decision is that we just trust what upstream say, then why not just unvendor them. Then many pieces of libraries can be reused by others. Shengjing Zhu signature.asc Description: PGP signature
Bug#971515: Status as of last tech-ctte meeting
On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote: > > 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. > In priciple, the kubectl compatibility matrix says it only supports one minor version (older or newer). When you working with many clusters, the cluster version may not be compatible with the kubectl version in Debian stable. PS, in practice, the basic function of kubectl doesn't change much, and new kubectl with old cluster seems to work. As a user of upstream kubectl package user, I'm quite happy with it. I can always install the latest, or any old version. They keep all old versions in their apt repo. And with the nature of static link, their repo works well other parts of the system, regardless I'm running Debian oldstable, stable, or unstable. IMO, we should admit that current Debian way doesn't fit well for such softwares. signature.asc Description: PGP signature
Bug#971515: kubernetes: excessive vendoring (private libraries)
On Tue, Oct 20, 2020 at 12:16:03PM -0700, Sean Whitton wrote: > > - are people trying to do cross-archive work going to find the packaging > of kubernetes getting in their way? (e.g. other Go team members > trying to update things, improve our binNMU techniques and machinery, > etc.) > The kubernetes maintainer is not in the Go packaging team, so doesn't follow the team practice. But as kubernetes vendor everything, it doesn't need to work with all other Go packages. However kubernetes is also a library, and the maintainer doesn't provide it. It becomes headache for other maintainers. We (the Go packaging team) need to vendor the kubernetes in our packages, for example: + https://sources.debian.org/src/golang-github-openshift-api/4.0+git20190508.81d064c-4/vendor/k8s.io/ + https://sources.debian.org/src/gitlab-ci-multi-runner/13.3.1+dfsg-1/vendor/k8s.io/ + https://sources.debian.org/src/flannel/0.9.1~ds1-1/vendor/k8s.io/ + https://sources.debian.org/src/consul/1.7.4+dfsg1-1/vendor/k8s.io/ And many, they can be found with: https://codesearch.debian.net/search?q=%22k8s.io%2F+filetype%3Ago=1 It has been asked at #970331, without response from maintainer. If kubernetes package want to make other package which Build-Depends on it to build successfully, it needs to decouple the dependencies from vendor dir. When building other packages, the Go toolchain can't use the vendor in kubernetes, since the Go toolchain only supports the top level vendor dir. The way the kubernetes maintainer chooses, is making others difficult. Every package that uses kubernetes as a library, has to keep a local copy of the source. It's not Janos fault, as he doesn't make things worse. Kubernetes package is in a bad state for a long time. But I hope Janos can cooperate with the Go packaging team to make Debian, especially the Go packages in Debian more maintainable. -- Shengjing Zhu signature.asc Description: PGP signature
