On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher <sgallagh(a)redhat.com> 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(a)lists.fedoraproject.org
>
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraprojec...
>