|
On 09/08/2016 11:27 AM, Stephen
Gallagher wrote:
On 08/22/2016 11:23 AM, Stephen Gallagher wrote:
On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
Hi!
As some of you may know, nodejs package that is present in
EPEL is pretty outdated. The current v0.10 that we have will
go EOL in October and npm (package manager) is already not
maintained.
Currently, upstreams' plan is to have two versions of Long
Term Support (LTS) at once, one in active development and one
in maintenance mode.
Currently active is v4, which is switching to maintenance in
April and v6 which is switching to LTS in October.
This is also reason why we would like to skip v4, although
both will get security updates. Nodejs v6 also comes with
newer npm and v8 (which might best be bundled, as it is in
Fedora and Software Collections) (v8 might concern ruby and
database maintainers, but old v8 package still remains in
the repo).
There was also an idea to have both LTS versions in repo,
but we're not quite sure, how we'd do it and if it's even a
good idea.
Also, another thing is, if it is worth of updating every year
to new LTS or update only after the current one goes EOL.
According to guidelines, I'd say it's the latter, but it's
not exactly how node development works and some feedback from
users on this would be nice, because I have none.
tl;dr Need to update nodejs, but can't decide if v4 or v6,
v4: will update sooner, shorter support (2018-04-01)
v6: longer support (2019-04-01), *might* break more things,
won't be in stable sooner than mid-October if everything
goes well
FYI, I think this tl;dr missed explaining why v6 won't be in stable until
mid-October. What Zuzana and I discussed on another list is that the Node.js v6
schedule has it going into LTS mode on the same day that 0.10.x reaches EOL.
However, v6 is already out and available. The major thing that changes at that
point is just that from then on, they commit to adding no more major features
(as I understand it). This is the best moment for us to switch over to it.
However, in the meantime we will probably want to be carrying 6.x in
updates-testing for at least a month prior to declaring it stable (with
autokarma disabled) with wide announcements about the impending upgrade. This
will be safe to do since Node.js 6.x has already reached a point where no
backwards-incompatible changes are allowed in, so we can start the migration
process early.
OK, as we stated before, we really need to get Node.js 6.x into the
updates-testing repository soon. We mentioned that we wanted it to sit there for
at least a month before we cut over, and "at least a month" means "by next week"
since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
* We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly
requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible
to resolve this with SCLs, but I am no expert there. Zuzana?
* Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6
and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL
or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the
bundled copy of OpenSSL because it includes patented algorithms that are not
acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's
OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the
base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a
parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the
openssl101e package available for EPEL 5) and patch our specfile to be able to
work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much
overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
OK, I spent far too much of today attempting to solve this problem. I got fairly
far into it, but at this point I have run out of time to work on it for the near
future.
What I have been trying to do:
I decided that the most expedient approach for EPEL 7 right now would be to
attempt to build OpenSSL statically into Node.js. We cannot do that with the
copy that upstream carries due to certain patents, so I decided to see if I
could script up something that would pull the source of the OpenSSL package from
Fedora Rawhide, drop it into the Node.js source tree and allow us to build it.
This sounds simple in theory, but it turns out that it's going to require a fair
bit of mucking about with the gyp build that Node.js uses. I've made some
headway on it, but I am running out of steam. I just don't have anywhere near
the level of knowledge of OpenSSL to make this work.
I've pushed my WIP to https://github.com/sgallagher/nodejs-fedora (the latest
commit in the master branch is the interesting piece). I'd really appreciate it
if someone else could take a look and try to help get it building under EPEL 7.
RDO in CentOS 7 (and soon the OpsTools SIG) are using this nodejs
patch which allows it to work with openssl 1.0.1:
https://github.com/rdo-common/nodejs/blob/rdo-common/0002-Use-openssl-1.0.1.patch
This patch has been approved by the crypto team.
_______________________________________________
epel-devel mailing list
epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
|
