F23 Self Contained Change: io.js Technology Preview

[Parag Nemade]

Hi,

On Mon, Jul 6, 2015 at 2:47 AM, T.C. Hollingsworth <
tchollingsworth at gmail.com> wrote:

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

Thanks,
Parag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150709/acee5f87/attachment.html>