On 12/26/2014 01:50 PM, Nico Kadel-Garcia wrote:
On Fri, Dec 26, 2014 at 4:02 PM, Vladimir Mosgalin
<[email protected]> 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
