[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: F23 Self Contained Change: io.js Technology Preview
From: Parag Nemade <panemade () gmail ! com>
Date: 2015-07-08 19:22:36
Message-ID: CALsL9AsG5OEmV6Z2iugNZYDxE+8xMQVOKbVmNuO6SiPrZmSe7A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
On Mon, Jul 6, 2015 at 2:47 AM, T.C. Hollingsworth <
tchollingsworth@gmail.com> wrote:
> On Wed, Jul 1, 2015 at 12:41 PM, Stephen Gallagher <sgallagh@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.
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic