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:[email protected] +1 (407) 489-7013 (Mobile) mailto:[email protected] (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/ _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
