Description of problem: Red Hat customers who enable the RHS Channel and EPEL have two conflicting sources of glusterfs. Version-Release number of selected component (if applicable): All How reproducible: Enable both RHS Channel and EPEL and do a YUM update or use the GUI to update the software. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: RHS rpm packages should use a name other than glusterfs*, e.g. rhs*
RHS rpm packages should use a name other than glusterfs*, e.g. rhs-glusterfs*
Kaleb/Vijay/Avati, Do we need a RPM spec change now (well, we are not clear of a better name as of now)? Sayan, how critical is it for release? how does this works for other packages in RHEL / Fedora model?
There have been a (small) number of complaints from the Fedora/EPEL community WRT the overlap. I suggest that the RHS version of the glusterfs packages be renamed to rhs-glusterfs* to disambiguate RHS RPMs from community gluster RPMs. The sooner this happens, the better, IMO. And yes, it requires that the RPM spec be renamed, e.g. to rhs-glusterfs.spec(.in). You've also got different versioning. The RHS RPM should, IMO, be version 2.0 for the upcoming release. This is another reason for changing the name, so as to minimize confusion. We do not want glusterfs-3.3.0 in Fedora/EPEL repos and glusterfs-2.0.0 in RHEL Storage Channel. I suspect that there will still be confusion, but rhs-glusterfs-2.0.0-1.el6.rpm in the RHEL Storage channel and glusterfs-3.2.7-1.el6.rpm in Fedora/EPEL will be less confusing than what we have today
Package rename not required, closing the bug.
RPM names in RHS 2.0 are glusterfs*-3.3.0-xx.el6rhs.x86_64. ^^^^^^ A perfectly acceptable solution, if I'm not mistaken. Why nobody mentioned it sooner is a mystery.