Bundling (was Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk))

[Nicolas Mailhot]

Le Mer 24 juillet 2013 16:17, Peter MacKinnon a écrit :

> A generalization which I would disagree with in the Java space. I think
> many projects
> eventually reach "steady-state" where they have acquired the set of dep
> bundles
> they need to satisfy their runtime and test requirements. For example,
> Hadoop
> would not bundle multiple versions of Jetty. However, it's bundled deps
> may differ
> slightly (perhaps even by just API-compatible versions) say from Tomcat's
> (another Hadoop dependency). And that's where you see the proliferation
> of bundled
> jar libraries as you walk down (up?) the dep tree.

Having been involved in java packaging in the past, I can only agree with
the generalization. Most java projects will affirm their bundling is
minimal, but java projects are deeply interconnected and unwinding
recursively the dependencies of the bundled deps (which can also do their
own 'sparse' bundling) always gave frightening results in my time. Java
projects only consider the tip of the iceberg. They quickly lose count of
the layers of obsolete components their bundled deps drag. And because
they lose count, they are not aware of the security problems that caused
each of those to become obsolete upstream in the first place.

I wouldn't object to bundling if the bundlers did due security diligence
on the bits they bundled. But they don't. That's the *only* reason they
feel bundling is cheaper. They skim on the security maintenance costs.

-- 
Nicolas Mailhot