Bug#971515: CTTE decision on "kubernetes: excessive vendoring (private libraries)"

2021-01-22 Thread Shengjing Zhu
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

Description: PGP signature

Bug#971515: Status as of last tech-ctte meeting

2020-11-19 Thread Shengjing Zhu
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

Description: PGP signature

Bug#971515: kubernetes: excessive vendoring (private libraries)

2020-10-22 Thread Shengjing Zhu
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/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:


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

Description: PGP signature