[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Packages duplicated between EL-5 sub-channels and EPEL

Stephen John Smoogen wrote:
On Mon, Jan 18, 2010 at 1:24 AM, David Juran <djuran redhat com> wrote:
On Mon, 2010-01-18 at 02:52 -0500, Jon Stanley wrote:
On Mon, Jan 18, 2010 at 2:41 AM, David Juran <djuran redhat com> wrote:

Sorry, what I meant was that the release number should be lower in EPEL.
I.e. the EPEL package would be identical to the RHEL one except that the
release number would be lower.
Generally with a package like 389 or something, you'll have a NEWER
version in EPEL than what is in the layered product channel, as EPEL
carries the upstream source. not the released source of the RH product
- therefore, unless development is stagnant (which one certainly hopes
is not the case), then the version in EPEL is necessarily going to be
newer than that in the respective RHN channel.

Am I missing something incredibly obvious here?
Maybe the point is moot now after Friday's meeting (which I didn't
attend due to real-life interference) but this really raises the
question, what is the purpose of EPEL?

*) Is it to provide cutting edge versions of layered products on top of
RHEL? Isn't running plain Fedora a better choice then? Of course I see
the point in getting more people to test e.g. the latest greatest 389
version. But is that really the primary mission for EPEL? And maybe it
still can be done by creating e.g. a 389-ds package (under the name
389-ds and taking care of file system conflicts) that doesn't conflict
with redhat-ds.

For many of the people who want to run/test Red Hat projects (cobbler,
satellite, ds) to test where the product is going Fedora makes NO
sense for them. They aren't looking to update daily to keep up with
fixes, their internal methodologies may require the base OS to go
through various tests which means the Fedora OS is nearly EOL before
they can use it, etc. Testing the products on what they deploy in
production is what they want to do. [I have worked in 3 different
places where I had to do this.. and before EPEL I would have to take
the Fedora stuff, recompile on RHEL and then test/debug what didn't
Right. Speaking for 389 - it seems that most people running 389 are trying to support long term production environments - they don't want to run Fedora on these environments - they don't want that sort of base OS churn on their production environments, but don't mind the churn of 389 (or they just pick and choose which releases to upgrade to). Many (I'm guessing roughly half) of 389 users run some sort of EL instead of Fedora.
*) Is it to provide layered products to those not willing to pay for Red
Hat support? Isn't that the mission of CentOS?

That is NOT what we are doing. If we were doing that we would be
taking the src.rpms from the channel and rebuilding them... (eg
centos-ds etc). What for the 389, cobbler, etc groups is a channel
where they can reach the people they are developing the product for
and give them the ability to give feedback.
And this feedback is extremely valuable. About half of 389 users run it on EL, some of them in high volume, long lasting production environments, and getting this sort of usage data and feedback from recent releases of 389 is invaluable to the 389 team. If we (389 team) had to, we would provide our own yum repo of EL packages (which we did for a couple of years until someone finally put 389 into EPEL).
*) Is it to provide Extra Packages for Enterprise Linux (-:
 I.e. a set of packages that for various reasons are not included in
RHEL but are in Fedora. That does not really imply that the version of
that extra package should be the latest end greatest version. In my
opinion, the package version in EPEL should mirror the stable policy of
RHEL by preferring stability over cutting-edge.

Well it might have been that but it would require more co-operation
from Red Hat to do that than I think is possible. By the time we find
out puppet, nagios, etc are in a RH subproduct the EPEL have already
been moved forward to meet bugs etc. Moving the packages back to -1
release means:

1) People who got a newer version of puppet,nagios, etc earlier will
not see any updates and their version may still break the RHN product
if they installed it.
2) People who do install the older version of puppet, nagios etc will
not see any upstream bugfixes because RH nor EPEL would update
regularly (looking at the updates to those subpackages in the
3) Removing, deprecating the packages on the list would hamstring
enough people that we might as well close shop.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]