Complete RHEL package lists?
ville.skytta at iki.fi
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
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