[Gluster-devel] EPEL YUM repos for Gluster, managing community glusterfs installs on RHEL
lmohanty at redhat.com
Wed Oct 22 14:21:31 UTC 2014
On 10/22/2014 06:40 PM, Kaleb S. KEITHLEY wrote:
> It has recently become more complicated to install community GlusterFS
> on RHEL due to competing client-side packages that are in RHEL 6.5,
> 6.6, and 7.x. Because the versions don't line up though, updates and
> installs are prone to failure. N.B. this is precisely why glusterfs
> was retired from Fedora EPEL circa the release of RHEL 6.5.
> To simplify installing community glusterfs going forward, our current
> thinking is to deploy a gluster-release RPM on download.gluster.org.
> This RPM will install an /etc/yum.repos.d/gluster.repo file with
> "priority=1" lines for each of the sub-repositories.
> By itself these added lines are a no-op.
> But if the system already has the yum-plugin-priority RPM installed
> this will result in the community glusterfs.repo being the preferred
> source of glusterfs RPMs, over-riding any other source of glusterfs RPMs.
> And we will suggest that users audit their system and install the
> yum-plugin-priority RPM if that suits their needs.
> Questions? Comments?
IMO we should not put priority related stuff in gluster-release RPM. I
am for a wiki page to give work around for issues like these. As these
are user decisions. As user should take decisons which repo should have
priority and value of the priority if he chooses this solution.
As of now we are assuming that upstream (download.gluster.org) will have
the right set of RPMs for users, but that might not be true. For e.g. in
future if someone wants to move to CentOS SIG packages then it would
need manual intervention.
I am not sure if we force yum to take packages from community repo i.e.
download.gluster.org then it is a clean solution . Because this brings
some risk for packages which is built on glusterfs e.g. qemu in RHEL
base. It might break them. Either way something might break and it does
not look like to be a clean and long term solution to me.
Also, I am against giving priority=1 to any repo. That actually makes it
repo with highest priority which is IMO not necessary. As repos without
priority (which is usually the case) , have priority=99 as default. So
any number less than that will give upstream repos higher priority .
More information about the Gluster-devel