On 18 September 2014 08:01, Dean Troyer <dtro...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
