Bug 1473088

Summary:	http-parser missing as a dependency
Product:	[Fedora] Fedora EPEL	Reporter:	prasun.gera
Component:	nodejs	Assignee:	NodeJS Packaging SIG <nodejs-sig>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel7	CC:	jamielinux, mrunge, nodejs-sig, piotr1212, prasun.gera, sgallagh, tchollingsworth, thrcka, zsvetlik
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-24 10:22:33 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description prasun.gera 2017-07-20 01:37:58 UTC

Description of problem:
Installing npm has some dependency issues on RHEL 7. One one system, it pulled in nodejs010-http-parser and nodejs010-runtime from my RH SCL channel. This eventually fails to find the library with the following error: "node: error while loading shared libraries: libhttp_parser.so.2: cannot open shared object file: No such file or directory" because the libraries are installed under /opt/rh as a part of the SCL package that it pulls in. Instead, it should have pulled in the http-parser package from EPEL. This has also been documented on this blog: https://medium.com/@genebean/node-js-centos7-and-libhttp-parser-so-2-abb725e1aae8. On a different system, it worked fine, and seems to have got the right dependency. I'm not sure what triggers it to pull in the SCL package.

Version-Release number of selected component (if applicable):
npm-3.10.10-1.6.10.3.1.el7.x86_64

How reproducible: Not sure


Steps to Reproduce:
1. sudo yum install npm

Actual results:
node: error while loading shared libraries: libhttp_parser.so.2: cannot open shared object file: No such file or directory

Expected results:
No Error

Additional info:

Comment 1 Piotr Popieluch 2017-07-20 13:03:39 UTC

I think this bug should be filed against node in scl, not node in epel. I don't know where SCL bugs are tracked.

Comment 2 Piotr Popieluch 2017-07-20 13:11:48 UTC

Ah, I think I misread. You don't want to use the SCL npm? Then yum erase it, disable the scl repo in /etc/yum.repos.d, verify EPEL repo is enabled and SCL disabled (yum repolist), and yum install it again.

Comment 3 prasun.gera 2017-07-20 20:01:17 UTC

npm is still installed from epel. It just fails to find the correct dependencies. i.e., If scl and epel are enabled, and you call yum install npm, you get something that doesn't work. If epel's npm needs epel's http-parser, it should be packaged that way.

Comment 4 Piotr Popieluch 2017-07-21 16:17:29 UTC

I think the issue is that nodejs010-http-parser.x86_64 provides a generic so library instead of the scl specific one. This seems to be fixed/improved in nodejs4 scl.

see:

$ dnf repoquery --provides rh-nodejs4-http-parser.x86_64
libhttp_parser.so.rh-nodejs4-2.7.0()(64bit)

vs:

$ dnf repoquery --provides nodejs010-http-parser.x86_64
libhttp_parser.so.2()(64bit)


As epel-npm (or actually nodejs) requires libhttp_parser.so.2 and the scl http-parser package claims to provide that I think this should be filed against nodejs-010-http-parser.


@zsvetlik: Could you comment on this as you know way more about scl than me?

Comment 5 Zuzana Svetlikova 2017-07-24 10:21:55 UTC

Yes, it is a bug in nodejs010-http-parser, but won't be fixed since nodejs010 SCL is EOL.

Did you try installing nodejs from epel-testing?

Comment 6 Zuzana Svetlikova 2017-07-24 10:22:33 UTC


*** This bug has been marked as a duplicate of bug 1457763 ***