On Wed, 23 May 2012 17:50:00 -0400
Bryan J Smith <email@example.com> wrote:
Hey Bryan, I wanted to answer some of your points, but this week has
been very hectic. ;(
> Enterprises who are customers of Red Hat run with all sorts of
> software, including IHV, ISV, and even custom or custom-rolled. The
> value of Extra Packages of Enterprise Linux (EPEL) is that they sport
> the Fedora guidelines and related advantages. It also leads a number
> of Red Hat customers to the Fedora project as maintainers too.
Absolutely. Also, it allows folks to share support costs with other
> But it's more than that, as you and others have identified. What
> versions will go in?
> Does EPEL match Red Hat Enterprise Linux layered products?
Well, that would depend on how the overlap is handled no?
> Or does EPEL stay more leading edge with Fedora as possible?
No. We have always agreed that EPEL was for enterprise use and rapid
incompatible upgrades don't work with that. Fedora also has the
advantge of releases every 6 months, so they can ask people to revisit
incompatible upgrades when they make that jump. RHEL upgrades much less
frequently, so we can't even use that very often to jump to a new
> Or does EPEL just avoid both, and ship what only complements and does
> not conflict with what is in Red Hat Enterprise Linux layered
> products, as the latter can can be built from source RPMs by
I think the thing people are finding difficult about this is "all
layered products", when many of them seem very niche/special purpose or
not very well known.
> And how does Fedora solve more leading edge desires in that case?
Well, Fedora doesn't need to worry about RHEL, but in general
incompatible upgrades happen at release boundries, which is every 6
months. So, a new thing comes up, you have to wait at most 6 months
(but less if you use rawhide or a branched version of the next
> Again, what is Extra Packages for Enterprise Linux? I guess that's
> what I'm asking.
"Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, Red Hat Enterprise Linux (RHEL),CentOS and Scientific Linux (SL)."
> Imagine a real-world enterprise with 5,000 systems. They have a RHN
> Satellite server or some other provisioning, deployment, management,
> etc... solution. They have various fractions of those systems using
> various, layered entitlements, in the 100s here for something, 10s for
> another, and probably the 1s for a select few (Directory, Satellite,
> etc... come to mind).
> How do I advise a customer regarding EPEL in this situation?
I would say:
On machines you need packages from EPEL:
* If they are general purpose machines that need a number of epel
packages and don't have layered products just enable the epel
* If they are specialized machines that do have layered
products/channels, don't enable EPEL. If you need EPEL packages,
include them specifically with 'includepkgs' (or whatever method).
Perhaps it would help to know cases where machines have specific
layered products enabled, but need a bunch of epel packages?
I mean if you have a cloud node, what EPEL packages would be needed
there? Wouldn't you just enable EPEL on the virtual machines _running_
on the cloud ?
> Now factor in the the community advocates in the commercial entity.
> They have been recommending they turn one of their useful, management
> packages into a Fedora project with a maintainer, telling management
> it will be built for RHEL in EPEL and they can deploy it to any and
> all systems. They want to share it with other enterprises, via the
> Fedora Project, so everyone can benefit.
> That's my world. I'm not trying to tell anyone what to do. But
> that's just my world. It exists. It's real.
I don't doubt it. Imput from your world is valuable to the
epel-devel-list mailing list