Hello Dmitry,

On Wed 21 Oct 2020 at 11:21am +11, Dmitry Smirnov wrote:

> On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote:
>> I think that my message [1] is what makes you think that the package
>> would not have got through NEW?
> It was not your message but my own experience with introducing of 100+ 
> packages through NEW, especially those ones with large burden of vendored 
> libraries, including Kubernetes. The main hassle usually is to convince FTP-
> masters when some vendoring is _necessary_ (case by case) and the usual 
> request is to package all vendored libraries separately. With rare exceptions 
> some (few) vendored libraries are allowed like when a library is a fork, 
> customised for the particular project and therefore not re-usable by other 
> software. Another example is when vendored library is an obsolete software 
> phasing out in future releases. Few micro-libraries might be tolerated when 
> vendored, especially when they are not widely used. Also vendoring might be 
> acceptable when software components with mutual/circular dependencies are 
> shipped in one or several name spaces - in other words when a software code 
> base is not from one name space but from several. None of those cases applies 
> to Kubernetes.
> A specific example (libpod/podman) is mentioned in 
>   https://lists.debian.org/debian-devel/2020/03/msg00441.html
>     "Podman was rejected due to "many embedded packages in vendor/" with only
>      6 or 7 private libs versus 120 libraries removed in favour of packaged
>      ones."

Fair enough, but again, this is about NEW as a review by experienced
packagers rather than NEW as a blocker for inclusion.

> If your concern is about security support then IMHO Kubernetes can not be 
> meaningfully supported from security prospective, with or without vendored 
> dependencies.

Fair enough.  In the -devel thread the security team indicated that they
thought they could do security support in the case where there is
vendoring.  It would be good to get more input from them in this bug.

> If Debian only cared about maintainers' convenience or reducing maintainers 
> efforts then Debian would not be what it is now. We favour technical elegance 
> often in expense of maintainers' comfort.

I don't think maintainers' comfort is part of Janos' motivation -- it's
the issue of not having recent Kubernetes in Debian at all.

>> Are there issues the TC should think about which do not fall under this
>> way of looking at things?  I.e., weighing the impact on people other
>> than Janos who want to work on the package, vs. the impact on people who
>> want recent kubernetes to be part in the archive at all?
> Is Debian ecosystem of packaged reusable libraries worth caring about?
> If so then why grant exception to one particular package? We have several (or 
> more) sophisticated Golang packages using hundreds of packaged libraries.
> In the early days of packaging Kubernetes we did not even have most 
> components packaged and I've been spending most effort on packaging, 
> introducing and stabilising dependency libraries.
> These days the major work has already been done and the argument for 
> monolithic vendoring is much weaker.
> [...]

I think that we can all agree with everything you've written about the
reasons why packaging components separately is better.  The problem is
that in this case the choice seems to be between not having recent
Kubernetes in Debian at all, or giving up on some of those advantages.

Sean Whitton

Reply via email to