Conversations with centos-devel

[Mark Chappell]

On 19 September 2010 20:29, Jesse Keating <jkeating at redhat.com> wrote:
> On 09/18/2010 11:10 AM, Paul Howarth wrote:
>> And if we do that, we should be able to clone RHEL Workstation packages
>> (the ones not in RHEL Server) and put them EPEL without causing issues
>> for RHEL Workstation users...
>>
>> Shouldn't we?
>>
>
> I'm of the opinion that we should still not do this, except for extreme
> situations.  EPEL was not meant to be an end-run around RHEL packages or
> RHEL pricing, and while we could technically do it and have less chance
> of hurting people's systems, I don't think EPEL is the place for that.
> There is plenty of room for a slightly more removed repository from EPEL
> where one could provide updated versions of packages.

Except that's not what we're talking about doing (the Fedora
discussion about recent versions of packages is separate).  *If* there
is no "productivity" channel for Server then we're not talking about
bypassing the pricing scheme, we're talking about something that
people just plain can't get through Red Hat.  Things like perl
packages which are in Workstation (b2 refresh) as dependencies for GUI
tools, but are used by server type services, eg RT, and which RHEL
Server doesn't provide.

The only time your argument hold up in this case is if there is a paid
for channel that provides the additional packages.  At which point
we'll need to decide which channels we're targeting.  What makes
things worse is that as RHEL becomes a more complex product, with more
bolt-ons and options, trying to create EPEL becomes more complex:
Exactly which combinations of channels and architectures are we aiming
to provide packages for?

With the perl tree this has become a nightmare, it was tough getting
things like RT in before when some packages were pinned to old
versions, but now you're suggesting that some we couldn't even have,
simply because a GUI happened to use it in RHEL Workstation?

However, at this point I am just going to say, let's wait until
details of how RHEL6 is going to be structured are public, so we can
at least make an informed decision and not do things that are going to
make Rel-Eng-EPEL's life difficult.  If this means that there's going
to be a lag of a few weeks before EPEL is completely ready, post GA,
then that's life.  If anyone wants to help get stuff ready, post GA
because they want to deploy ASAP well they can always help with the
EPEL effort, we are after all simply volunteers.


Mark