Before long RHEL will ship selected client-side-only glusterfs RPMs and
it will become necessary to withdraw glusterfs (and hekafs) packages
from EPEL.
If you haven't followed along in fedora-devel, here's (what I think is)
a fairly cogent, if terse, summary of what I'd like to do.
And FWIW, glusterfs in EPEL is past its sell-by date anyway. I.e. it's
3.2.7, and Fedora and the rest of the world are shipping 3.4.1, so even
if RHEL wasn't going to force the issue, it should be withdrawn one way
or another.
Questions? Concerns?
-------- Original Message --------
Subject: Re: how to withdraw glusterfs from epel?
Date: Fri, 18 Oct 2013 09:49:54 -0700
From: Toshio Kuratomi <a.badger(a)gmail.com>
Reply-To: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
To: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
On Fri, Oct 18, 2013 at 11:06:31AM -0400, Kaleb S. KEITHLEY wrote:
On 10/18/2013 10:54 AM, Steve Gordon wrote:
>
>Would it be against the guidelines to move to packaging it (the software itself, not
a repo file) in Fedora/EPEL as glusterfs-community?
>
I'm sure it is against the guidelines. Under any name it'd still be
shipping a set of RPMs that conflict with RPMs in the RHEL base
channel — or will be soon.
And just to be clear, it's already been made clear that a repo file
is not acceptable.
Now I'm asking if I can morph the packaging (for EPEL) from several
glusterfs-*.RPMs to a single glusterfs-community-doc (or something
similar) RPM containing a README. This is instead of completely
withdrawing "community glusterfs" from EPEL.
I think that would be acceptable. It's content rather than code so falls
under this section of the fedora packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
Since this is for epel only, you probably want to talk to the other epel
maintainers about whether they have any issue with this plan but I don't
think it violates any Fedora Packaging Guidelines.
-Toshio