EPEL + EUS (Extended Update Support) [aka zStream]

[Bryan J Smith]

On Tue, 2010-05-11 at 14:23 -0500, BJ Dierkes wrote:
> Hello all,
> I wanted to ping the list for your thoughts on EUS/zStream [1] as it
> relates to EPEL. I've asked in an IRC meeting before but the general
> consensus was EPEL wasn't going to bother with EUS.

Not being in the IRC, is the current EPEL system (via Koji and other
facilities) capable of building for EUS v. just the lead EL update?
That would be my first, technical question.

> The issue is, my company is evaluating the use of EUS however we also
> have the requirement of offering custom packages and EPEL.  But
> subscribing EPEL (built against RHEL 5.5) to an EUS box running RHEL
> 5.3 [for example] has the potential to break things (ehhem libevent).
> Currently my options are to a) rebuild EPEL packages against each EUS
> point release on my own, or b) maintained point-in-time repos that
> simply provide all the packages when that point release was last
> updated and then no longer update that EPEL channel (not a good
> scenario).

My client has both EUS and taps EPEL, allowed by official policy.

We maintain internal EPEL repositories on our RHN Satellite Servers.
EPEL is cloned as a child channel under each EUS base channel anyway, so
we already have "b" by default, without doing anything else.  If we want
"a", it's just a matter of a rebuild.  We haven't needed to yet.

Yes, there is the potential to run into a newer EPEL package that would
break in on a previous, EUS release system.  But again, we haven't run
into it yet.  At the same time, EUS releases are only maintained for
around a year.  EUS is designed for transition, to minimize breakage
during transition.

So if you have EUS, you might already be doing "b" if you maintain your
own repositories (such as we do in Satellite).  So it really comes to do
doing "a" only when needed.  Not sure if that's really something that
falls to EPEL.  After all, EUS is really only offered for maximizing
integration/regression issues during a transition.

There's no guarantee that an update in EPEL won't cause such anyway,
even for the leading update, from a previous EPEL package release.  It's
up to Fedora Project maintainers to create backports, and not just
rebase an update.

At least that is my view.


-- 
Bryan J Smith       Senior Consultant       Red Hat, Inc
Professional Consulting http://www.redhat.com/consulting
mailto:bjs at redhat.com         +1 (407) 489-7013 (Mobile) 
mailto:b.j.smith at ieee.org  (Blackberry/Red Hat-External) 
-------------------------------------------------------- 
You already know Red Hat as the entity dedicated to 100%  
no-IP-strings-attached, community software development.   
But do you know where CIOs rate Red Hat versus other      
software and services firms for their own, direct needs,
year after year?     http://www.redhat.com/promo/vendor/