Open Stack

On 18 September 2014 08:01, Dean Troyer <dtroyer at gmail.com> wrote:
> Interestingly enough, the distros are doing exactly what they don't want us
> to do, ie, rebuilding things to use 'their' tested version of dependencies
> rather than the included one...

Indeed - but the distros are solving for two specific issues:

1) Effort by the distro team

1a) 'how to minimise effort delivering up-to-date packages when the
package count is 20k+'.  This is a pure numbers game: update one
binary on a users system, or 10, or 20 etc. Things deep down a
dependency tree can turn up in huge numbers of places, if vendoring is
commonplace.

1b) 'how to security fix packages where the upstream has stopped being
responsive' - updating vendored trees is often harder than just
unpacking a new release, since they may have deltas in addition to
being vendored - and vendoring may also require patches (depending on
the language). Just waiting for a new vendor release can be a long
process sometimes :)

And both of these are in the context of

2) how to fix things promptly for users

2a) binary packages are often quite substantial - particularly for
some c++ programs - a non-binary delta based approach (and thats what
all the distros started with) will consume a tonne of bandwidth if you
have to multiply out the uses of a package.

2b) distros were privileged in our modern responsible disclosure world
(via the vendor-sec list - I'm not sure what the current state of play
is) - but at one point they found out about security issues *before*
small consumers of packages do, and would fix it and then the upstream
release is made.

You can see, I think, how vendoring plays havoc with the amount of
effort a small team has to exert to keep a large set of packages
patched ahead of upstream releases of the vendored libraries. Its not
an intrinsic problem - its a problem we've constructed by centralising
and limiting notifications of CVEs: unless requests authors are part
of the urllib3 security response team, they can never respond to CVE's
in as timely a manner *while vendoring is in use*.

...
> FWIW I totally understand the desire for vendoring...I want to do the same
> thing with OSC because of the number of times we've been broken by requests,
> prettytable and others changing out from under us.  It is easy enough for me
> to fix my box but a cloud user that just want to get his VMs running isn't
> going to be happy, especially on Windows.
>
> dt

OOI were thouse changes API breaks or were we depending on nonpublic aspects?

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud