Lalatendu Mohanty
2014-Oct-22 14:21 UTC
[Gluster-users] EPEL YUM repos for Gluster, managing community glusterfs installs on RHEL
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