Complete RHEL package lists?
mmcgrath at redhat.com
Mon Aug 27 21:05:54 UTC 2007
Ville Skyttä wrote:
> 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.
Exact same thing happens if RH decides to include it in an update.
>> 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.
I'm just saying that trying to put strict guidelines/lists around
something that is very murky requires a lot of effort and the outcome is
bound to be unreliable. The fact is what RH does or does not decide to
ship is up to them and it is a completely unpredictable unordered
process which we are trying to bring order to. That said, if someone
wants to do the work and thinks they can make it reliable, have at it :)
More information about the epel-devel-list