RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Joe Julian]

On 12/06/2012 08:58 AM, Dmitry Makovey wrote:
> Based on some of the previous discussions on this thread, my own
> self-interests and looking around why not settle for "epel-rawhide" repo
> that could serve both as a QA stage for packages in EPEL and for the
> category of users who need "latest and greatest" version of package in RHEL.
>
> I do believe both groups: a) users who want stable b) users who want
> latest are quite sizable and have enough people involved to power such
> move.
>
> To address the security concerns: we need something that will require
> version bump whenever upstream drops maintenance of the currently
> packaged version in EPEL and there are no takers for backports within a
> week. That should minimize backporting efforts.
>
> just my $.02CDN

Taking that a step further, if a packager is unwilling or unable to 
backport security fixes, not adding them to the stable repo doesn't 
change anything from the way it's handled presently. With the way it is 
now where upgrades can break your system, you can't update your packages 
anyway so you're still not getting security updates. At least a 
multi-pronged repo would offer that possibility.

Taking, for instance, glusterfs since I'm familiar with the evolution, 
epel-5 had the very broken 2.0 versions. Those will never get any more 
bugfixes or security patches. epel-6 had 3.2 which has had several 
critical patches and will likely get security updates for a while 
longer. 3.3 is not compatible with the 3.2 rpc but is much more stable 
and is the recommended version to use by those of us that support 
glusterfs. For that, Kaleb maintains a fedorapeople repo.

Kaleb's not the only one who supports a newer version of a software in 
their own fedorapeople repo because it breaks backward compatibility. 
Todd Zullinger

Having an epel-N-rawhide repo would be one easy way to allow packagers 
to present the best of their package while leaving a stable repo to 
minimize the amount of maintenance required by an admin.

I admin 200 systems as just one guy. I don't have time to read every 
package release. I have to count on stable packaging to not break 
things. Those things that I want or need bleeding edge packaging are the 
only ones I track regularly. I don't need to know that libxml2 fixed the 
out of range heap access in 2.7.6-8.el6_3.4 if it doesn't break 
something. I don't need to know that Cuba switched to DST  in tzdata.

So, I would get behind this, or a "Incompatible-With: " yum/rpm concept 
that's also being discussed. Really, I'd get behind anything that 
doesn't require me to read every changelog and prevents (or at least 
makes it more difficult to have) system outages due to automated updates.