On 12/26/2014 01:50 PM, Nico Kadel-Garcia wrote:
> On Fri, Dec 26, 2014 at 4:02 PM, Vladimir Mosgalin
> <[log in to unmask]> wrote:
>> Hi Yasha Karant!
>>
>>   On 2014.12.26 at 12:50:33 -0800, Yasha Karant wrote next:
>>
>>> Test Transaction Errors:   file /usr/bin/event_rpcgen.py conflicts between
>>> attempted installs of compat-libevent14-1.4.13-1.rhel6.i686 and
>>> libevent-devel-2.0.19-1.rhel6.i686
>>>    file /usr/lib/libevent_core.a conflicts between attempted installs of
>>> compat-libevent14-1.4.13-1.rhel6.i686 and libevent-devel-2.0.19-1.rhel6.i686
>>>    file /usr/lib/libevent_core.so conflicts between attempted installs of
>>> compat-libevent14-1.4.13-1.rhel6.i686 and libevent-devel-2.0.19-1.rhel6.i686
>>>    file /usr/lib/libevent_extra.a conflicts between attempted installs of
>>> compat-libevent14-1.4.13-1.rhel6.i686 and libevent-devel-2.0.19-1.rhel6.i686
>>>    file /usr/lib/libevent_extra.so conflicts between attempted installs of
>>> compat-libevent14-1.4.13-1.rhel6.i686 and libevent-devel-2.0.19-1.rhel6.i686
>>>
>>> End output.
>>>
>>> Do I manually rm the files listed above?  Is there a yum erase command that
>>> I must issue, and if so, for which RPMs?
>> Please don't rm files (it will cause trouble to your system and won't
>> solve the problem as rpm checks file conflicts against its own db, not
>> filesystem). If you don't mind tricking rpm somewhat for the time being,
>> check my other mail for a guide.
> Yasha is a bit unusual: he consistently has  a model of "how things
> would work if they were done sensibly" which does not match the actual
> technologies or tools supported by the system.
>
> The first likely problem is below:
>
> Setting up Install Process
> Loading mirror speeds from cached hostfile
>   * elrepo-extras: reflector.westga.edu
>   * epel: mirrors.kernel.org
>   * rpmfusion-free-updates: mirror.web-ster.com
>   * rpmfusion-nonfree-updates: mirror.web-ster.com
>   * sl: ftp1.scientificlinux.org
>   * sl-addons: ftp1.scientificlinux.org
>   * sl-security: ftp1.scientificlinux.org
>   * sl6x: ftp1.scientificlinux.org
>   * sl6x-fastbugs: ftp1.scientificlinux.org
>   * sl6x-security: ftp1.scientificlinux.org
>
> Note the intermingling of sl6x with rpmfusion, epel, and
> elrepo-extras. There is no guarantee of compatiblity among these three
> added 3rd party repositories. In this case, it looks like a relevant
> "compat-libevent14.i686" is not being found. That one is from the
> postgresql repo, which I do not see in the mentioned repolist above.
> You *cannot* rely on randomly turning on, an doff, yum repositories to
> add relevant packages only when you feel like it, you will run
> precisely this kind of problem.
>
> Do a "yum list extras" to review packages from repositories that are
> not currently enabled, and then go get and install the relevant
> missing matching components. In this case, I think you'll fine
> compat-libevent14.i686 in the same postgresql yum repository you were
> using before. Frankly, I suspect Yasha has incomplete sets of
> libraries, namely .x86_64 and not .i686 libraries, from that
> postgresql repository which he enabled, then disabled.
>
>
>> --
>>
>> Vladimir
You are correct -- although the Add/Remove Software GUI shows that the 
postgresql repo
(the release version recommended by Vladimir, not the highest/most 
recent production revision level) is both installed and active.

As a general comment, I understand the risks of multiple possibly 
incompatible repositories.  However, in many cases, I have abandoned 
building from source because of highly variable dependencies 
(environments) required; thus, I attempt to download RPMs that will 
install executables.  Ideally, the various binary executables would be 
fully encapsulated (e.g., static images that do not required dynamic 
load libraries), but this typically is not the case.  In reality, the 
executables for specific applications appear in one of the possibly 
incompatible repositories, but not in another or the base SL 
distribution.  The other issue is the requirement to use proprietary 
vendor supplied packages for which source is not available (e.g., Adobe 
Acroread, Nvidia CUDA supporting drivers). Some of these vendor packages 
install better than others (e.g., Oracle Virtualbox thus far has worked 
with no installation issues).

I shall try the workarounds from Vladimir, but I am concerned about the 
possibility of an unstable environment, depending which applications 
depend upon or interact with these "packages" .  At the point, I 
seriously am considering a generally recommendation for all machines for 
which I have "responsibility" to only run SL 7.

There has been a discussion that EL is primarily a server environment.  
However, I found no licensed-for-free workstation distribution that is 
not in something akin to beta or is highly unfriendly to anyone who 
wants more than a MS Windows level end user environment.

Yasha Karant