On Wed, 23 May 2012 17:50:00 -0400
Bryan J Smith <b.j.smith(a)ieee.org> wrote:
Hey Bryan, I wanted to answer some of your points, but this week has
been very hectic. ;(
...snip...
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
interested parties.
...snip...
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
incompatible version.
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
downstream?
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
release).
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)."
?
...snip...
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
repo/channel/whatever.
* 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
discussion. ;)
kevin