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