On 05/30/2014 01:58 PM, Les Mikesell wrote: > On Fri, May 30, 2014 at 12:09 PM, Jim Perrin <jperrin at 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20140602/44a82171/attachment-0004.sig>