EPEL Fwd: Re: how to withdraw glusterfs from epel?

[Kaleb S. KEITHLEY]

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 
Reply-To: Development discussions related to Fedora 

To: Development discussions related to Fedora 

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/Guidelines#...

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

[Chris Adams]

Once upon a time, Kaleb S. KEITHLEY  said:
> 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.

Does it really make sense to package a README that just points to
another repo somwhere else?  Are there admins that find EPEL but can't
find other repos?

I definately see retiring the obsolete packages, but what is gained for
EPEL to package READMEs telling people that bother to read them to
install another repo.

[Stephen John Smoogen]

On 18 October 2013 12:32, Kaleb S. KEITHLEY  wrote:
> 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?

Personally I think the plan to have a README pointing to the newer
locations to follow the  "Don't be crappy" model as best we can.

[Paul DeAudney]

> Personally I think the plan to have a README pointing to the newer
> locations to follow the  "Don't be crappy" model as best we can.

If you do that then the sysadmins will need to bother with package exclude
lists on their EPEL repos.
For those who use puppet to manage yum repos that isn't much of a problem
if you have lots of machines. For people who like to use cpanel and don't,
then they're going to have a fair bit of manual work to do.

IMO don't bother creating a package with just a README in it in EPEL.