Packages duplicated between EL-5 sub-channels and EPEL

[Rich Megginson]

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