Packages duplicated between EL-5 sub-channels and EPEL

[Stephen John Smoogen]

On Mon, Jan 18, 2010 at 1:24 AM, David Juran <djuran at 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 at 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
work.]

> *) 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.

> *) 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
channel).
3) Removing, deprecating the packages on the list would hamstring
enough people that we might as well close shop.


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning