The quality of EPEL is not good? EPEL is pretty much the de facto semi-official add-on repository for RHEL. It is maintained by the same people as Fedora.
Posted Apr 21, 2010 20:49 UTC (Wed) by jspaleta (subscriber, #50639)
[Link]
It could be better integrated into the RHEL experience. EPEL runs up against some of the same problem that any 3rd party repository split does when it comes to policy synchronization. Debian certainly has some advantage in the fact that they don't have a split between "supported" and "unsupported" repositories.
Are paying RHEL customers sufficiently interested in EPEL as a resource to start talking to Red Hat about working to better integrate EPEL into the RHEL experience? I'm not a paying customer, but as an EPEL maintainer I'd love to know what the RHEL customers are looking for as a starting point for for a roadmap for better integration.
-jef
RHEL 6 beta version available
Posted Apr 21, 2010 21:49 UTC (Wed) by Banis (guest, #59011)
[Link]
As a RHEL customer with 1500 deployed boxes I've had a fair bit of trouble with EPEL. The packages are managed to haphazardly. Some stuff gets pulled out of Fedora at the latest version, some gets old versions and some get left out. EPEL also doesn't play nice with other third party RHEL repos that have more history behind them. The packages also do not tag themselves as being EPEL in the package name. The package release gets tag'd with el5 and the Vendor is left at Fedora Project. I know where I got the various packages because there in carefully separated local repo's, but EPEL not claiming any of the packages needs to be fixed. They are not supported by redhat and should thus not carry the .el5 tag at the end of the release.
I finally just pulled all the EPEL stuff off my network and rolled my own straight out of Fedora for anything I need not already provided by RHEL5.
And for the record a 2 year release cycle for our OS would be a problem for us. It takes 4 months to just deploy all our boxes (they are scattered in groups of 10 all over the US with a few in Korea). We'd probably end up skipping every other release if they come to fast, but that has it's own issues.
RHEL 6 beta version available
Posted Apr 21, 2010 22:13 UTC (Wed) by sjlyall (subscriber, #4151)
[Link]
I didn't actually realise EPEL was "official". It does seem a little nicer than some but not great.
For instance the memcached package is from July last year and won't work with libevent-1.4 in RHEL 5.5
I grabbed a Package list for RHEL 6 and out of the packages I'm interested in the following are newly added:
memcached
tokyo cabinet
But the following are missing which I would have liked to see (especially nginx and puppet).
nginx
puppet
collectd
Mondo rescue
tokyo tyrant
cassandra
I'm trying to work out how to submit a wishlist ticket to RHEL support.
RHEL 6 beta version available
Posted Apr 22, 2010 0:27 UTC (Thu) by jspaleta (subscriber, #50639)
[Link]
An updated memcached is in updates-testing.
updates in EPEL have to spend a certain amount of time in updates-testing before they are released to stable...or enough people give it positive karma.
That's done to help in QA. As an EPEL user you could help by giving it some positive karma in the update system
But I understand the gist of what you are saying. I'll try to state it more exactly.
Because RHEL and EPEL are distinct repositories they have distinct management policies. EPEL tries to provide as coherent an update policy as can be expected given that RHEL's build system is distinct from EPEL's.
Currently there's no way to do a coordinated push, EPEL doesn't get access to RHEL update packages any earlier than RHEL users do. So as a result there will be a lag in EPEL update availability.
Can the volunteer, community run, EPEL do better at serving RHEL customers? I'd like to hear some suggestions on that. For package coordination, its difficult for me to see how. Unless Red Hat is willing to work with us to do coordinated builds prior to RHEL updates going out to the public, the lag will remain.
As an EPEL maintainer, I'd certainly appreciate if customers would let Red Hat know they'd like to see better coordination in updates between RHEL and EPEL. I'd love to see a public discussion between Red Hat, RHEL customers, and EPEL contributors on where the low hanging fruit is.
-jef
RHEL 6 beta version available
Posted Apr 22, 2010 17:21 UTC (Thu) by Banis (guest, #59011)
[Link]
I have to apologize for my complaints about EPEL. I did not realize EPEL was not fully managed by redhat. Last time I had a redhat sales guy out he all but claimed the project himself. I assumed redhat was building the packages internally as a way to provide RHEL folks with a broader package set.
RHEL 6 beta version available
Posted Apr 22, 2010 17:46 UTC (Thu) by jspaleta (subscriber, #50639)
[Link]
Well it's certainly nice to know that Red Hat sales team is aware of the work and sees it as a valuable thing to talk about.
It's not surprising that EPEL's role was miscommunicated.
Getting a good idea of internal Red Hat corporate culture perception of Fedora and EPEL can be harder than gauging public perception.
What I would LOVE to see is a high profile public meeting of the minds between Red Hat reps, EPEL maintainers, and a panel of RHEL customers about how a roadmap for making it easier for customers to utilize AND contribute to EPEL and a set of accurate talking points about where EPEL fits in as a value proposition.
There's a lot of room to grow EPEL to better meeting customer needs...but that growth has to either come from sweat-equity from customers themselves contributing to EPEL and shaping it directly or be driven by customer cash channelled through Red Hat to pay for the manhours to build the infrastructure to make RHEL/EPEL synchronization more coherent than it is now. I'm an EPEL maintainer, but I'm not a RHEL customer and so I can't really speak to how EPEL fits into the RHEL customer experience. But what I need is for the conversation to happen in the open. If its always a conversation between a salesperson and a RHEL (potential) customer there's no way I can constructively shape that conversation.