Project

General

Profile

Actions

Bug #11809

closed

ceph.spec.in fails on rhel7

Added by Loïc Dachary almost 9 years ago. Updated almost 9 years ago.

Status:
Won't Fix
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Steps to reproduce

--> Finished Dependency Resolution
Error: Package: gperftools-devel-2.1-1.el7.x86_64 (epel)
           Requires: gperftools-libs(x86-64) = 2.1-1.el7
           Installed: gperftools-libs-2.1-1.el7cp.x86_64 (@rhel-7-server-ceph-1.3-mon-test)
               gperftools-libs(x86-64) = 2.1-1.el7cp
           Available: gperftools-libs-2.1-1.el7.x86_64 (epel)
               gperftools-libs(x86-64) = 2.1-1.el7
Error: Package: leveldb-devel-1.12.0-5.el7.x86_64 (epel)
           Requires: leveldb(x86-64) = 1.12.0-5.el7
           Installed: leveldb-1.12.0-5.el7cp.x86_64 (@rhel-7-server-ceph-1.3-mon-test)
               leveldb(x86-64) = 1.12.0-5.el7cp
           Available: leveldb-1.12.0-5.el7.x86_64 (epel)
               leveldb(x86-64) = 1.12.0-5.el7

Files

a.txt (29.8 KB) a.txt full output of install-deps.sh Loïc Dachary, 05/29/2015 09:36 AM
Actions #1

Updated by Loïc Dachary almost 9 years ago

Actions #2

Updated by Loïc Dachary almost 9 years ago

Ken: I've assigned this to you so you can triage it, there is no urgency ;-)

Actions #3

Updated by Ken Dreyer almost 9 years ago

I wonder if you locked a magna node that someone didn't clean up before they unlocked it and released it into the pool? "rhel-7-server-ceph-1.3-mon-test" looks suspicious...

Actions #4

Updated by Vasu Kulkarni almost 9 years ago

Can you please tell the name of the hostname? , I think its due to someone having /etc/yum.repos.d/ceph.repo along with epel.repo, I think one of the repo should be deleted, As Ken said its due to not proper cleanup.

Actions #5

Updated by Loïc Dachary almost 9 years ago

this is Shylesh Kumar machine, I'm not sure how it was configured. It is hp-ms-01-c02.moonshot1.lab.eng.rdu

Actions #6

Updated by Ken Dreyer almost 9 years ago

why is Shylesh running ./install-deps.sh there?

Actions #7

Updated by Loïc Dachary almost 9 years ago

for the purpose of testing a problem with LRC. we were trying to reproduce the conditions by using part of the tests from the sources.

Actions #8

Updated by Vasu Kulkarni almost 9 years ago

In the above case it is going to conflict with downstream packages, maybe he can force install specific packages then.

Actions #9

Updated by Loïc Dachary almost 9 years ago

In the above case it is going to conflict with downstream packages, maybe he can force install specific packages then.

It is not to install anything, just using things compiled from source, within the source directory.

Actions #10

Updated by Ken Dreyer almost 9 years ago

From a technical perspective the issue is that the downstream repos (rhel-7-server-ceph-1.3-mon-test is a downstream thing) do not ship packages that 100% match what EPEL ships. For example, we ship gperftools-libs, but we block gperftools-devel from shipping, because we don't expect Ceph end users to need this, and we don't want to imply that we "support" general compilation against gperftools, etc.

In the yum operation above, ./install-deps.sh tries to install gperftools-devel, but that package is only available in EPEL, and it requires "el7" (EPEL) instead of "el7cp" (downstream RHCS).

To summarize, if you want ./install-deps.sh to succeed on this server, you'll need to uninstall the downstream packages first so that the EPEL packages can install.

EDIT: you'll need to 1) uninstall the downstream packages, and 2) disable the rhel-7-server-ceph-1.3-* repos too.

Actions #11

Updated by Loïc Dachary almost 9 years ago

  • Status changed from New to Won't Fix

since it's supposed to not work, I'm good with it. Thanks for the workaround.

Actions

Also available in: Atom PDF