Hello,
With SCL and epel repositories enabled, some dependencies for the package name 'nodejs' get satisfied with libs from SCL which are placed in paths that are not part of my user's environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?
For example, the http parser dependency gets satisfied by nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_6
http-parser-2.0-4.20121128gitcd01361.el6.x86_64 : HTTP request/response parser for C Repo : epel Matched from: Filename : /usr/lib64/libhttp_parser.so.2 Other : libhttp_parser.so.2()(64bit) Filename : /usr/lib64/libhttp_parser.so.2.0
http-parser-2.0-4.20121128gitcd01361.el6.i686 : HTTP request/response parser for C Repo : epel Matched from: Other : libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2.0
nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_64 : HTTP request/response parser for C Repo : scl Matched from: Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2 Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2.0 Other : libhttp_parser.so.2()(64bit)
On Fri, May 30, 2014 at 11:18 AM, Eugene Vilensky evilensky@gmail.com wrote:
Hello,
With SCL and epel repositories enabled, some dependencies for the package name 'nodejs' get satisfied with libs from SCL which are placed in paths that are not part of my user's environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?
Exclude them from the SCL repo? [0] ( Or instead just include what you want from the SCL repo via includepkgs=. )
exclude=*nodejs*
[0] http://www.cyberciti.biz/faq/redhat-centos-linux-yum-update-exclude-packages...
For example, the http parser dependency gets satisfied by nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_6
http-parser-2.0-4.20121128gitcd01361.el6.x86_64 : HTTP request/response parser for C Repo : epel Matched from: Filename : /usr/lib64/libhttp_parser.so.2 Other : libhttp_parser.so.2()(64bit) Filename : /usr/lib64/libhttp_parser.so.2.0
http-parser-2.0-4.20121128gitcd01361.el6.i686 : HTTP request/response parser for C Repo : epel Matched from: Other : libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2.0
nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_64 : HTTP request/response parser for C Repo : scl Matched from: Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2 Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2.0 Other : libhttp_parser.so.2()(64bit) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/30/2014 10:18 AM, Eugene Vilensky wrote:
Hello,
With SCL and epel repositories enabled, some dependencies for the package name 'nodejs' get satisfied with libs from SCL which are placed in paths that are not part of my user's environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?
EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you're installing the package from, and be careful with the package name itself. There shouldn't be duplicate names.
In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user's environment)
For example, 'scl enable nodejs010 bash' would give you a bash shell with the appropriate environment for using the nodejs from SCL.
For example, the http parser dependency gets satisfied by nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_6
http-parser-2.0-4.20121128gitcd01361.el6.x86_64 : HTTP request/response parser for C Repo : epel Matched from: Filename : /usr/lib64/libhttp_parser.so.2 Other : libhttp_parser.so.2()(64bit) Filename : /usr/lib64/libhttp_parser.so.2.0
http-parser-2.0-4.20121128gitcd01361.el6.i686 : HTTP request/response parser for C Repo : epel Matched from: Other : libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2.0
nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_64 : HTTP request/response parser for C Repo : scl Matched from: Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2 Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2.0 Other : libhttp_parser.so.2()(64bit) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, May 30, 2014 at 12:09 PM, Jim Perrin jperrin@centos.org wrote:
EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you're installing the package from, and be careful with the package name itself. There shouldn't be duplicate names.
In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user's environment)
Hi Jim,
I'm afraid I'm definitely using the EPEL package name but the resolved dependency for http-parser is from SCL: Perhaps because the SCL version of http-parser is a higher version?
https://gist.github.com/evilensky/75febbdfbdeb49a3142f
Thanks everyone for the suggestions.
On 05/30/2014 12:50 PM, Eugene Vilensky wrote:
On Fri, May 30, 2014 at 12:09 PM, Jim Perrin jperrin@centos.org wrote:
EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you're installing the package from, and be careful with the package name itself. There shouldn't be duplicate names.
In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user's environment)
Hi Jim,
I'm afraid I'm definitely using the EPEL package name but the resolved dependency for http-parser is from SCL: Perhaps because the SCL version of http-parser is a higher version?
That can happen with the SCL repo ... in cases where you are getting something you don't want from SCL, exclude it via the CentOS-SCL.repo file in /etc/yum.repo.d/
A line that says:
exclude=nodejs0*
should take care of that problem.
If you are not using any SCLs, then you can disable the repo ... IF you want to use both nodejs's and EPEL's does not work with the RHEL nodejs too, then they need to fix it as you should be able to install and use both.
On 05/30/2014 12:50 PM, Eugene Vilensky wrote:
On Fri, May 30, 2014 at 12:09 PM, Jim Perrin jperrin@centos.org wrote:
EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you're installing the package from, and be careful with the package name itself. There shouldn't be duplicate names.
In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user's environment)
Hi Jim,
I'm afraid I'm definitely using the EPEL package name but the resolved dependency for http-parser is from SCL: Perhaps because the SCL version of http-parser is a higher version?
https://gist.github.com/evilensky/75febbdfbdeb49a3142f
Thanks everyone for the suggestions.
That can happen with the SCL repo ... in cases where you are getting something you don't want from SCL, exclude it via the CentOS-SCL.repo file in /etc/yum.repo.d/
A line that says:
exclude=nodejs0*
should take care of that problem.
If you are not using any SCLs, then you can disable the repo ... IF you want to use both nodejs's and EPEL's does not work with the RHEL nodejs too, then they need to fix it as you should be able to install and use both.
On Fri, May 30, 2014 at 12:09 PM, Jim Perrin jperrin@centos.org wrote:
With SCL and epel repositories enabled, some dependencies for the package name 'nodejs' get satisfied with libs from SCL which are placed in paths that are not part of my user's environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?
EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you're installing the package from, and be careful with the package name itself. There shouldn't be duplicate names.
In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user's environment)
Is yum supposed to track the dependencies separately? That is, if an EPEL package requires some other package (expected with the stock paths), can an SCL package fulfill that dependency even though it will be installed in a location that won't work?
On 05/30/2014 01:58 PM, Les Mikesell wrote:
On Fri, May 30, 2014 at 12:09 PM, Jim Perrin jperrin@centos.org wrote:
With SCL and epel repositories enabled, some dependencies for the package name 'nodejs' get satisfied with libs from SCL which are placed in paths that are not part of my user's environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?
EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you're installing the package from, and be careful with the package name itself. There shouldn't be duplicate names.
In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user's environment)
Is yum supposed to track the dependencies separately? That is, if an EPEL package requires some other package (expected with the stock paths), can an SCL package fulfill that dependency even though it will be installed in a location that won't work?
SCL's require that you properly configure them to work with the system ... you CAN likely use that version IF you modify the environment for the program in question. Or you can use the EPEL version and exclude nodejs010 from the SCL's .repo file in /etc/yum.repo.d/
SCL's are not automatically set up, as they are designed to only be used when properly configured and should live alongside other older packages. As such, they require added knowledge and administrative overhead, much like multiple 3rd party repos can ... but they also provide lots of added capabilities.
On Mon, Jun 2, 2014 at 6:55 AM, Johnny Hughes johnny@centos.org wrote:
On 05/30/2014 01:58 PM, Les Mikesell wrote:
Is yum supposed to track the dependencies separately? That is, if an EPEL package requires some other package (expected with the stock paths), can an SCL package fulfill that dependency even though it will be installed in a location that won't work?
SCL's require that you properly configure them to work with the system ... you CAN likely use that version IF you modify the environment for the program in question. Or you can use the EPEL version and exclude nodejs010 from the SCL's .repo file in /etc/yum.repo.d/
SCL's are not automatically set up, as they are designed to only be used when properly configured and should live alongside other older packages. As such, they require added knowledge and administrative overhead, much like multiple 3rd party repos can ... but they also provide lots of added capabilities.
That seems pretty dangerous if the packages replace standard or EPEL libraries/components. I'd have expected them to have some sort of namespace concept for dependencies to keep the sets of packages completely independent. That is, I thought being independent was the point. Shouldn't you be able to have multiple versions installed?
On 06/02/2014 07:47 AM, Les Mikesell wrote:
On Mon, Jun 2, 2014 at 6:55 AM, Johnny Hughes johnny@centos.org wrote:
On 05/30/2014 01:58 PM, Les Mikesell wrote:
Is yum supposed to track the dependencies separately? That is, if an EPEL package requires some other package (expected with the stock paths), can an SCL package fulfill that dependency even though it will be installed in a location that won't work?
SCL's require that you properly configure them to work with the system ... you CAN likely use that version IF you modify the environment for the program in question. Or you can use the EPEL version and exclude nodejs010 from the SCL's .repo file in /etc/yum.repo.d/
SCL's are not automatically set up, as they are designed to only be used when properly configured and should live alongside other older packages. As such, they require added knowledge and administrative overhead, much like multiple 3rd party repos can ... but they also provide lots of added capabilities.
That seems pretty dangerous if the packages replace standard or EPEL libraries/components. I'd have expected them to have some sort of namespace concept for dependencies to keep the sets of packages completely independent. That is, I thought being independent was the point. Shouldn't you be able to have multiple versions installed?
I consider this a bug, as the SCL's should be self-contained. We'd need to see if this occurs upstream as well, and then file a bug there if so.
On Mon, Jun 2, 2014 at 8:53 AM, Jim Perrin jperrin@centos.org wrote:
That seems pretty dangerous if the packages replace standard or EPEL libraries/components. I'd have expected them to have some sort of namespace concept for dependencies to keep the sets of packages completely independent. That is, I thought being independent was the point. Shouldn't you be able to have multiple versions installed?
I consider this a bug, as the SCL's should be self-contained. We'd need to see if this occurs upstream as well, and then file a bug there if so.
There's really a bigger issue of how EPEL is supposed to fit in the world of 'other' repositories. What should happen when centosplus/extras has a same-named package? Other 3rd parties?
On 06/02/2014 10:06 AM, Les Mikesell wrote:
On Mon, Jun 2, 2014 at 8:53 AM, Jim Perrin jperrin@centos.org wrote:
That seems pretty dangerous if the packages replace standard or EPEL libraries/components. I'd have expected them to have some sort of namespace concept for dependencies to keep the sets of packages completely independent. That is, I thought being independent was the point. Shouldn't you be able to have multiple versions installed?
I consider this a bug, as the SCL's should be self-contained. We'd need to see if this occurs upstream as well, and then file a bug there if so.
There's really a bigger issue of how EPEL is supposed to fit in the world of 'other' repositories. What should happen when centosplus/extras has a same-named package? Other 3rd parties?
Then you have to figure it out ... it happens. Many different repos have packages with the same name. If the repos don't play nicely with each other, well then that is their fault. Garbage in / Garbage out.
On Mon, Jun 2, 2014 at 10:15 AM, Johnny Hughes johnny@centos.org wrote:
I consider this a bug, as the SCL's should be self-contained. We'd need to see if this occurs upstream as well, and then file a bug there if so.
There's really a bigger issue of how EPEL is supposed to fit in the world of 'other' repositories. What should happen when centosplus/extras has a same-named package? Other 3rd parties?
Then you have to figure it out ... it happens. Many different repos have packages with the same name. If the repos don't play nicely with each other, well then that is their fault. Garbage in / Garbage out.
The typical scenario is that EPEL doesn't initially have a package so you have to get it from some other repository. Then EPEL adds it, but with different build/configuration options so every time the updates leapfrog your system breaks. Is this really not a solvable problem? Should we just expect EPEL to wantonly clobber anything, including Centosplus/extras?
On 06/02/2014 10:06 AM, Les Mikesell wrote:
There's really a bigger issue of how EPEL is supposed to fit in the world of 'other' repositories. What should happen when centosplus/extras has a same-named package? Other 3rd parties?
https://yourlogicalfallacyis.com/pdf/FallaciesPoster16x24.pdf I'll let you pick the appropriate one for your argument.
Naming is a separate issue that applies to all repos. EPEL isn't special in that regard. It's also not part of the issue here. The problem here is an extraneous Provides that's pulling in the wrong package.
Top posting:
Seems someone's already filed this as a bug. You can keep an eye on the progress via -> https://bugzilla.redhat.com/show_bug.cgi?id=1042879
Similar bug impacting SSSD -> https://bugzilla.redhat.com/show_bug.cgi?id=1089090
On 05/30/2014 10:18 AM, Eugene Vilensky wrote:
Hello,
With SCL and epel repositories enabled, some dependencies for the package name 'nodejs' get satisfied with libs from SCL which are placed in paths that are not part of my user's environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?
For example, the http parser dependency gets satisfied by nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_6
http-parser-2.0-4.20121128gitcd01361.el6.x86_64 : HTTP request/response parser for C Repo : epel Matched from: Filename : /usr/lib64/libhttp_parser.so.2 Other : libhttp_parser.so.2()(64bit) Filename : /usr/lib64/libhttp_parser.so.2.0
http-parser-2.0-4.20121128gitcd01361.el6.i686 : HTTP request/response parser for C Repo : epel Matched from: Other : libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2 Filename : /usr/lib/libhttp_parser.so.2.0
nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.centos.alt.x86_64 : HTTP request/response parser for C Repo : scl Matched from: Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2 Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2.0 Other : libhttp_parser.so.2()(64bit) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Eugene Vilensky -
Jim Perrin -
Johnny Hughes -
Johnny Hughes -
Les Mikesell -
SilverTip257