Description of problem: nodejs Requires: http-parser >= 2.7.0 but there is no http-parser in EPEL Version-Release number of selected component (if applicable): nodejs-1:6.11.1-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. yum install nodejs Actual results: Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel) Requires: libhttp_parser.so.2()(64bit) Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel) Requires: http-parser >= 2.7.0 Expected results: Should install without errors Additional info: Seems like http-parser used to be in EPEL but according to current mirrors it is not any more.
I have seen https://src.fedoraproject.org/rpms/http-parser/c/38ad9debf904ba21277e7a569366cca5b7c2a26b?branch=epel7 BTW. This just breaks anyone that is not on RHEL 7.4. Is there any reason that http-parser cannot live in both RHEL 7.4 and EPEL, at least for some reasonable amount of "bridge" time until everyone can reasonably be expected to get updated to 7.4?
So, clearly this is a duplicate of bug 1481008 however I disagree with the NOTABUG assessment there. In the context of the EPEL project, I would maintain that this is a bug. Not everyone is able to upgrade to RHEL 7.4 as immediately as it is released. Some IT departments have processes that a new release has to go through before it can be deployed. RHEL is also not the only consumer of EPEL. Is it the intention of EPEL to ignore these non-RHEL distros? TBH, I'm not entirely clear of the mandate of the EPEL project. Is it intended to be a resource for the EL user-base at large or is it only focused on and concerned with RHEL specifically?
(In reply to Brian J. Murrell from comment #1) > I have seen > https://src.fedoraproject.org/rpms/http-parser/c/ > 38ad9debf904ba21277e7a569366cca5b7c2a26b?branch=epel7 BTW. > > This just breaks anyone that is not on RHEL 7.4. > > Is there any reason that http-parser cannot live in both RHEL 7.4 and EPEL, > at least for some reasonable amount of "bridge" time until everyone can > reasonably be expected to get updated to 7.4? Yes, unfortunately this particular package hit an edge-case that causes problems. When RHEL 7.4 was released, the http-parser package that was included in RHEL ended up with a name-version-release (NVR) value that sorts as _older_ than the one provided by EPEL. What this means is that the version contained in the EPEL repository would be superseding the official one provided by RHEL, thus resulting in RHEL users being out of support for anything that depends on http-parser which includes both Node.js and the SSSD project. As these are critical parts of many setups, we need to avoid it. Normally, the RHEL maintainers keep an eye on packages that are in EPEL and try to ensure that when adoing them to official RHEL repositories that they bump the release to make sure it replaces the EPEL package. Unfortunately in this particular case, the maintainer didn't realize this and we ended up in this situation. There are no good solutions here, but we opted for dropping the package from EPEL so that we don't impact the support compliance of anyone using RHEL. I wish there was a way to address this that didn't negatively impact the CentOS users, but it *will* be fixed as soon as CentOS finishes its 7.4 update (which I honestly expected would have been available by now). You're probably right that "NOTABUG" isn't the appropriate resolution. I'm going to mark this as CANTFIX instead.
*** Bug 1481507 has been marked as a duplicate of this bug. ***
(In reply to Stephen Gallagher from comment #3) > the maintainer didn't realize this and we ended up in > this situation. Oh. What an unfortunate situation then. I understand what has gone wrong. It's just a pity is all. > There are no good solutions here, Are the update-release processes for RHEL just too heavy to allow getting a RHEL 7.4 update out that bumps the NVR of http-parser to that above what is in EPEL in quick enough order? > You're probably right that "NOTABUG" isn't the appropriate resolution. I'm > going to mark this as CANTFIX instead. Sounds good. It may seem a trivial difference but those two resolution codes send very different messages. Thanks for taking the time to explain the situation.
I should also ask, is it still not worthwhile, even if it takes a while, to get an NVM bumped http-parser into RHEL 7.4 such that you can restore the EPEL one also, just for those folks that are stuck on EL < 7.4 (i.e. while it's regression tested by IT departments, etc.)?
(In reply to Brian J. Murrell from comment #6) > I should also ask, is it still not worthwhile, even if it takes a while, to > get an NVM bumped http-parser into RHEL 7.4 such that you can restore the > EPEL one also, just for those folks that are stuck on EL < 7.4 (i.e. while > it's regression tested by IT departments, etc.)? I have made that request into RHEL already. No decision on the issue (either way) has yet been made public. It was suggested offline by Zuzanna that we could temporarily bundle http-parser in Node.js, which I wish I had thought of last week. At this point, I think it's unlikely that a Node.js update carrying the bundled copy would make it out of the epel-testing repository faster than just waiting for CentOS to release the http-parser package, but we can at least have it in testing as a temporary solution.
nodejs-6.11.2-1.2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1788cd6310
Is this new nodejs-6.11.2-1.2.el7 package missing "Obsoletes: http-parser < $something" and "Provides: http-parser == $something" tags of some kind? How will people who currently have nodejs and http-parser installed as separate packages upgrade to this nodejs and not end up with file conflicts?
(In reply to Michael Chapman from comment #9) > Is this new nodejs-6.11.2-1.2.el7 package missing "Obsoletes: http-parser < > $something" and "Provides: http-parser == $something" tags of some kind? How > will people who currently have nodejs and http-parser installed as separate > packages upgrade to this nodejs and not end up with file conflicts? The temporary bundled version is statically compiled into the binary. It does not put libhttp_parser.so.* into /usr/lib[64], so it will coexist fine with the existing package.
nodejs-6.11.2-1.2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1788cd6310
Now nodejs and npm packages install from epel-testing, but fail when trying to install anything with npm. Tested with latest centos:7 Docker image: yum install -y epel-release yum install --enablerepo=epel-testing npm nodejs [root@d4f742f16b96 /]# npm install bower npm: relocation error: npm: symbol SSL_set_cert_cb, version libssl.so.10 not defined in file libssl.so.10 with link time reference
Stephen Gallagher, if you break users like this for a significant span of time, then please provide some reasonable workaround, like uploading the original package to some trustworthy-looking URL and linking to it. Looks like all the mirrors have already deleted the original http-parser-2.7.1-3.el7.x86_64.rpm :( The CentOS 7.4 Continuous Release repository doesn't yet have any packages and a release is probably still several weeks away. The only workaround I found is installing the http-parser package from Springdale Linux: http://springdale.math.ias.edu/data/puias/unsupported/7/x86_64/http-parser-2.7.1-3.sdl7.x86_64.rpm For reference, the cause of this issue is bug 1477662.
http-parser is still available from koji yum install https://kojipkgs.fedoraproject.org//packages/http-parser/2.7.1/3.el7/x86_64/http-parser-2.7.1-3.el7.x86_64.rpm nodejs That said, nodejs is installed from epel, not epel-testing and npm works fine.
It looks like the OpenSSL 1.0.1 compatibility patch must have been broken in the latest testing release. Fortunately, RHEL 7.4 now provides 1.0.2, which will allow us to drop that patch. Unfortunately, that's yet another piece that doesn't really line up with CentOS... I'm *not* going to be bundling OpenSSL from upstream because it's known to carry patent-encumbered codecs that are not allowed in Fedora/EPEL. So at this point, I think we have the following choices: 1) Downgrade to the last known version that we know the SSL patch worked on and carry bundled http-parser with it. 2) Try to fix the OpenSSL 1.0.1 patch (CCing someone who might be able to help) 3) Just move ahead with the version that works with RHEL 7.4 and deal with the fact that CentOS is running behind. I'm inclined to go with 3) because it's the least error-prone and most supportable. People who have chosen to run CentOS know that the trade-off is that it will always trail RHEL. If they need packages faster than CentOS can provide, they can always go get a subscription. I hate that this got broken, but between http-parser and OpenSSL, there's really not a lot of good options.
nodejs-6.11.2-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1788cd6310
OK, after investigation, this cannot be made to work without requiring OpenSSL 1.0.2 as well (at least, it cannot be made to work without spending more effort than makes sense since CentOS 7.4 is due any day now). As a result, I've just pushed out a newer version of the package for EPEL 7 that just explicitly requires OpenSSL 1.0.2 at runtime. This *will not work* on CentOS until CentOS 7.4 is released. I do apologize for the inconvenience, but I've exhausted the available workarounds.
OK, thankfully CentOS 7.4 development is now far enough that the CR repository works. https://wiki.centos.org/AdditionalResources/Repositories/CR Just run this: yum-config-manager --enable cr && yum update
*** Bug 1487941 has been marked as a duplicate of this bug. ***
A slightly more conservative approach: yum-config-manager --enable cr yum install nodejs # or update ... yum-config-manager --disable cr