[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: Rethinking EPEL at FUDcon Lawrence 2013



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.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]