On Tue, 2010-05-11 at 14:23 -0500, BJ Dierkes wrote:
I wanted to ping the list for your thoughts on EUS/zStream  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
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
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
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:firstname.lastname@example.org +1 (407) 489-7013 (Mobile)
mailto:email@example.com (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/