<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 6, 2015 at 2:47 AM, T.C. Hollingsworth <span dir="ltr">&lt;<a href="mailto:tchollingsworth@gmail.com" target="_blank">tchollingsworth@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Wed, Jul 1, 2015 at 12:41 PM, Stephen Gallagher &lt;<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>&gt; wrote:<br>
&gt; So this was discussed at today&#39;s FESCo meeting[1]. Basically, we&#39;re not<br>
&gt; sure that it makes sense to have both interpreters in the distribution,<br>
&gt; particularly since they are merging back together in the future.<br>
&gt;<br>
&gt; Would you be willing to consider just packaging io.js *as* node.js in<br>
&gt; Fedora 23? Among other things, this would avoid the need to go through<br>
&gt; additional package reviews, rebuild nodejs-* packages to work with<br>
&gt; io.js, etc.<br>
&gt;<br>
&gt; My limited understanding of io.js is that it is essentially a superset<br>
&gt; of node.js functionality,<br>
<br>
</span>This is correct.  It has additional features but is broadly compatible<br>
with the ecosystem of packages available via npm.<br>
<span class=""><br>
&gt; so it seems like just moving to this instead<br>
&gt; of node.js 0.12.0 would make sense.<br>
<br>
</span>I&#39;m fine with moving the default engine in Fedora 23 to io.js.<br>
<br>
I&#39;m not so fine with still calling the package we ship io.js in<br>
&quot;nodejs&quot;, since it&#39;s not node.js, and we can&#39;t be entirely sure the<br>
next version of node.js will be greater than the current version of<br>
io.js (although I believe that is the plan).<br>
<span class=""><br>
&gt; Otherwise, will this Change require building NPM packages for iojs<br>
&gt; -&lt;module&gt; rather than (or in addition to) nodejs-module? Can this be<br>
&gt; avoided by running them with an alternatives-provided /usr/bin/node?<br>
<br>
</span>No.  Only binary modules would require special iojs-foo cousins due to<br>
the different binary compatibility surface of the two engines.  These<br>
would be built from the SRPMS that already exist.  While binary module<br>
SRPMs would require changes, none would be necessary for<br>
pure-JavaScript modules.<br>
<br>
npm does not offer any ability to ship different code when different<br>
node.js/io.js versions are used, so it really isn&#39;t necessary for us<br>
to either.  The vast majority of all code in the ecosystem will either<br>
Just Work or detect and do the right thing at runtime.  We also don&#39;t<br>
really have the resources to maintain two separate stacks of<br>
JavaScript applications, as you&#39;re rightly concerned about.<br>
<br>
Therefore, we do not intend to support shipping different versions of<br>
pure-JavaScript nodejs software for different engines, though it of<br>
course will be possible to express that a particular package only<br>
works/doesn&#39;t work with a particular engine via Requires/Conflicts.<br>
<br>
Note that all of the above is a concern for the SIG even if we only<br>
ship io.js in Fedora, as I&#39;d eventually like to get 0.12 into EPEL<br>
without leaving 0.10 users in the dust.  My intention was to design<br>
the binary SRPM build logic such that the same SRPM would build<br>
nodejs-foo and iojs-foo cousins on Fedora and nodejs0.10-foo and<br>
nodejs0.12-foo cousins on EPEL with no spec changes.<br>
<br>
So remember that some big changes are coming to nodejs-packaging and<br>
binary module SRPMs anyway, the only question is which branches<br>
they&#39;re landing in.  ;-)<br>
<div class=""><div class="h5"><br></div></div></blockquote><br></div><div class="gmail_quote">Can you please add this information on change wiki page as well?<br><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">Parag.<br></div></div></div></div>