<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"><<a href="mailto:tchollingsworth@gmail.com" target="_blank">tchollingsworth@gmail.com</a>></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 <<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>> wrote:<br>
> So this was discussed at today's FESCo meeting[1]. Basically, we're not<br>
> sure that it makes sense to have both interpreters in the distribution,<br>
> particularly since they are merging back together in the future.<br>
><br>
> Would you be willing to consider just packaging io.js *as* node.js in<br>
> Fedora 23? Among other things, this would avoid the need to go through<br>
> additional package reviews, rebuild nodejs-* packages to work with<br>
> io.js, etc.<br>
><br>
> My limited understanding of io.js is that it is essentially a superset<br>
> 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>
> so it seems like just moving to this instead<br>
> of node.js 0.12.0 would make sense.<br>
<br>
</span>I'm fine with moving the default engine in Fedora 23 to io.js.<br>
<br>
I'm not so fine with still calling the package we ship io.js in<br>
"nodejs", since it's not node.js, and we can'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>
> Otherwise, will this Change require building NPM packages for iojs<br>
> -<module> rather than (or in addition to) nodejs-module? Can this be<br>
> 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'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't<br>
really have the resources to maintain two separate stacks of<br>
JavaScript applications, as you'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'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'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'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>