On Fri, Jan 15, 2010 at 12:29 PM, Michael Stahnke <mastahnke(a)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(a)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