Unfortunately none of this discussion solves the substantive issue which is that we cannot release an xstatic package without breaking the gate.
We currently have one solution that's a close to viable as we've been able to get: move the version pinning for xstatic packages out of upper-constraints and into Horizon's repository, and hope that the app-catalog server and Horizon stay in step or that they're never installed on the same debian/redhat system (or if they *are* then one of them is installed in a virtualenv). Richard On 17 March 2016 at 19:00, Thomas Goirand <z...@debian.org> wrote: > On 03/17/2016 07:23 AM, Richard Jones wrote: > > There's a basic difference here though. Your traditional "installed > > components" are pieces of software and data used *by programs on that > > system.* > > > > The components we're talking about here are, as far as the system is > > concerned, opaque data to be transmitted over HTTP(S) to a web browser > > client which then makes use of that data in some manner. > > > > There are no cross-program compatibility issues stemming from having > > multiple different versioned copies of such client-side files on a > > system > > The same way, we could have multiple version of fonts, tzdata, SSL root > certificates and so on. There wouldn't be any compatibility issues. > Though it's still not the right thing to do at a distribution level. > > Have you noticed also that in the Windows world, each program carries > its .dll, which are supposed to be shared object, but in fact, they > aren't shared? Yes, it is easier to do so. > > > - this is why the web development world has standardised on > > tooling that *makes it easy to do so*. Different client-side web > > applications *should* be able to use different versions of components. > > The same was as for shared .so libraries, that's not the correct way to > do things. Even though the JavaScript objects aren't executed by the > system (well, if we forget that nodejs exists), there's still potential > bugs and security problems with them, and they may require maintenance. > > > xstatic shoe-horns that freedom of client-side application component > > usage into a one-size-must-fit-all world that fundamentally only exists > > because programs on a system can get confused when multiple versions are > > installed on that system[1]. > > I wouldn't say it this way. To me, they are just tools which makes it > easy for us to stop the duplication madness of the same files. > > Have a look: > # apt-file search jquery.js | grep -v doc | wc -l > 128 > > This is 127 bugs which should be fixed currently with the embedded > jquery. I hardly see how one could argue this is a good thing. I hope we > can be better citizens than this. > > Cheers, > > Thomas Goirand (zigo) > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev