Packages duplicated between EL-5 sub-channels and EPEL

[Stephen John Smoogen]

On Fri, Jan 15, 2010 at 12:29 PM, Michael Stahnke <mastahnke at gmail.com> wrote:
>>
>> The problem with that is that you would need something like:
>>
>> epel-base: packages that don't conflict with any known RH channels
>> epel-not-ds: packages that don't conflict with RH DS channel
>> epel-not-sat: packages that don't conflict with RH Satellite channel
>> ...
>
> The more I think about it, the more I think the root cause of these
> issues is Red Hat not trying (very hard) to work with EPEL.  The
> steering committee has tried a number of times to get a point person
> involved in RHEL and other products to act as an interface for EPEL
> and had only minimal success.  I have a few questions for RH in
> general, and their view of EPEL.
>
> 1.  When Red Hat decides to pull a package into RHEL or a layered
> channel, where do they pull the package from? It's been quite obvious
> they don't pull from EPEL source as they have released versions below
> what EPEL has in the repo on several occasions. Was there any effort
> to use the EPEL package, or work with the current maintainer of the
> package in the EPEL/Fedora space?

Ok the first issue is a common one that people have when dealing with
a group.. expecting the group to have one policy that everyone will
follow etc. For the purposes of this discussion, there is no 'Red Hat'
deciding things... there are a couple hundred developers deciding
things as best they can at some particular moment..

Some will pull something out of Fedora, some will package it up
(either because they don't think to look in EPEL or Fedora or what was
there didn't meet what they wanted.) The second issue is that EPEL
moves forward faster than RH products do. A package may be pulled out
of EPEL but when it finally comes out its been 3-6 months and whats in
EPEL has moved on. Or the developer will stick in stuff into EPEL that
people don't want because its too new (cobbler development was this
way).

> 2.  Does Red Hat want EPEL to have the tools system administrators and
> developers commonly need?  I understand RH offering additional
> packages for an additional subscription.  If a company sees value in a
> subscription, they will buy it.  However, if my company had to buy a
> channel for puppet, nagios, createrepo, etc, it would not be cost
> effective to use RHEL at all.

This question can't be answered due to the fact that there is no one
Red Hat policy/group.

Red Hat would need to be an ultra fascist organization where everyone
gets a brain implant that the Black Committee would toggle to say "We
all do this". Red Hat is too much a free-form meritocracy where you
have 400 developers saying 800 things, 100 marketing people saying
1000 other things, and half a dozen VP's coming up with even more
things, and 1500+ support people having to deal with all the
permutations that come from what development, marketing, sales, etc
have put out.

It is much better to deal with it like you deal with the kernel. We
can ask Linus for general things... but in the end getting him to say
that all developers will do this and this is not going to happen. [It
is one of those things that people coming into the company seem to
have to learn over and over again.. they can raise the staff of Aaron
over their head as many times as they want... the water will part when
it damn well pleases.]

> 3.  Does RH publish what packages they have available in all channels
> anywhere publicly?  That way, EPEL could be slightly more agile in its
> ability to block/update/manage package changes impacted from RH.

I don't think so as most of the channels are run by separate groups.
Most have their own sub-cultures and release structures. I will say
that seeing what was in ftp.redhat.com seemed a vast improvement over
the years.

> At the RH Summit, RH preaches involvement from the community and
> specifically the Fedora community however, it is a two-way street.
> EPEL can't just react to every change that Red Hat decides to make and
> on RHEL and have it work perfectly each time.  EPEL tries hard to be
> the best package repository it can be, because we believe in the RHEL
> family of products, however we are only on the receiving end.
>
> I realize I haven't offered a whole lot of solutions here, but if we
> had more information it may be easier to come to agreement on one.
>
> stahnma
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>



-- 
Stephen J Smoogen.

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