Complete RHEL package lists?

Ville Skyttä ville.skytta at
Mon Aug 27 20:34:52 UTC 2007

On Monday 27 August 2007, Mike McGrath wrote:
> Personally I think documenting these processes is a lot of work with
> questional benefit.  It seems to me more logical to be reactive to
> this.

I'm afraid I'll have to disagree here and would not be comfortable with using 
packages from or seriously contributing to such a project.  Mileages vary, of 
course, but I'd be surprised if it were just me.

One Scenario: work hard to produce a great package of something popular and 
complex, succeed, get it through the review process, ship it in EPEL.  Months 
pass, users are happy, and build things on top of the EPEL package and its 
configuration.  Then, someone finds out that there's a conflict/unwanted 
upgrade or something like that problem with the package and something in some 
channel or derivative distro.

I can't come up with a good way to react to this kind of a situation without 
breaking something, and just throwing things out there to see if something 
breaks is not what I'd expect from a project like EPEL.  The _best_ case is 
that people report the problem and the reactive fix will "only" result in 
wasted packager/maintainer/reviewer resources.

> When something comes up that is a conflict, remove / fix it in epel.

Conflicts are kind of easy as the probability of damage done to existing end 
user installations is pretty low because the package didn't actually get 
installed, but unwanted and incompatible upgrades which do get installed and 
start to cause problems afterwards are not.

More information about the epel-devel-list mailing list