On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher <sgall...@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@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Reply via email to