<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On Jun 13, 2014, at 8:00 AM, <a href="mailto:lsb-discuss-request@lists.linux-foundation.org">lsb-discuss-request@lists.linux-foundation.org</a> wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Wed, Jun 11, 2014 at 02:31:34AM +0300, Net Kgk wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Ruby is popular. Perl is popular. Javascript is popular. Any<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">programing language, if it has some practical use is popular and have<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">some community, so why chose only one of them?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">As far as I know, javascript is the most popular scripting language<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ever. Besides it is much more readable and faster than python. So why<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">python? Just because of the fact that some distros like RedHat and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Gentoo was so stupid to chose python as programming language for their<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">packaging systems? Why not use Suse experience, then? Is it worst, or<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">something?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Perhaps you're not aware of the LSB's primary goal --- which was not<br></blockquote><blockquote type="cite">to annoint one or more languages as willing some perceived "Language<br></blockquote><blockquote type="cite">War", but rather to promote the ability for third-party distributed<br></blockquote><blockquote type="cite">software packages (particularly those that were shipping compiled<br></blockquote><blockquote type="cite">binaries) to be usable across multiple distributions.<br></blockquote><blockquote type="cite"><br></blockquote><br><div>There are no licensing restrictions on RPM code and tests exist for RPM.</div><div><br></div><div>Surely all ISV's -- those funding LSB or not -- benefit from a "standard" software</div><div>distribution format.</div><div><br>Meanwhile you (as former CTO of LSB) are recommending that rpm packages <br>should be in a format that was abandoned and is nowhere in use. The LSB</div><div>infrastructure is offering a perl script to produce rpm packages because</div><div>the existing specification and tests are too weak to attempt an implementation.</div><div><br></div><div>The number of LANANA registered "lsb-" names is of order 20 when typical distros</div><div>are composed of thousands of *.rpm packages.</div><div><br></div><div>And LSB itself doesn't provide software packages conformant to the</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>LSB Package Spec</div><div><br></div><div>LSB has punted the uplift of the LSB packaging spec for 2 full release cycles now</div><div>(LSB 4.x and 5.0).</div><div><br></div><div>LSB has also rejected a FL/OSS implementation of the<br>"Berlin API", designed and promoted by Ian Murdock (and presumably LSB) itself.<br><br>So why was RPM chosen to be included in the LSB Core specification?<br><br>73 de Jeff<br></div></body></html>