Gabriel Hurley wrote: > 2. Bundling LESS vs. other means: If you think downstream packagers don't > like node... pretty much nobody packages LESS. The recommended way to install > LESS is actually with NPM (the Node Package Manager). We could install it > that way, but that makes dependency management even more complicated. The > important bit is that people need to use a relatively consistent version of > LESS, otherwise very hard-to-debug differences in parsing and feature support > creep in. So the options became "package the very small, similarly licensed > binary" or "make the dependency mess even larger than it has to be".
Bundling external code because it's not (yet) packaged is, IMHO, a short-term solution. The end goal is to properly depend on separately-packaged software, so that we avoid a long-term mess of code duplication. LESS sounds like a much easier thing to package compared to Node.js ? As far as the "relatively consistent version of LESS" is concerned, you can have a strong dependency on a precise version of LESS (or a range of versions that you support). Obviously ">=" deps are preferable, but distributions usually prefer strong deps to code duplication. Code duplication may sound like an innocent thing to do, but they are a nightmare for distributions, who must provide security support for all the software they distribute. They can easily match a Horizon CVE to the Horizon package and update it. They can easily match a LESS CVE to a LESS package and update it. But they have to special-case you to remember that a LESS CVE actually also affects the Horizon package. It's a lot less work to get that stuff properly packaged and remove any duplication. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
