On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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: Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side tag to build it into. Will make it easier so you don't need to deal with a billion build overrides etc. Peter > 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? > > > _______________________________________________ > epel-devel mailing list > epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
