[Gluster-devel] EPEL YUM repos for Gluster, managing community glusterfs installs on RHEL

[Lalatendu Mohanty]

On 10/22/2014 06:40 PM, Kaleb S. KEITHLEY wrote:
> Hi,
>
> 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?
>

+ gluster-users

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 [1].

[1] 
https://docs.fedoraproject.org/en-US/Fedora/14/html/Software_Management_Guide/ch06s14.html

Thanks,
Lala