F23 Self Contained Change: io.js Technology Preview
tchollingsworth at gmail.com
Sun Jul 5 21:17:11 UTC 2015
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. 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
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
Therefore, we do not intend to support shipping different versions 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. ;-)
More information about the devel