On Mon, Jun 11, 2012 at 12:13 PM, Bryan J Smith b.j.smith@ieee.org wrote:
Bryan J Smith wrote:
... That now begs the question if the EL Rebuilds will now just stop building them since they are available in EPEL? If so, now Fedora EPEL becomes the concentrator for EL Rebuilds. ... Expectations are extremely fluid here and I see much harm to the entire community-sustaining engineering duality ... ...
Understand at some point I'm feeling I'm "alone" in many viewpoints and wonder if I should bother any further. I'm surprised many are not seeing my point, but maybe this final attempt will clear it up.
In all of these posts that I have responded to, in countless scenarios put forth, I'm seeing one party ignored over and over, and the only one always ignored.
The paying Red Hat customer who helps fund the sustaining engineering.
In many cases where EPEL build and ships Red Hat packages, even entire add-ons -- things that were in AS/AP, things that were in CentOS Extras, etc... -- the "EL Rebuilds" can just move to ship the EPEL packages instead of having to build their own independent.
So if you are on just a base Red Hat entitlement, or with an EL Rebuild that moves to remove duplications with EPEL, you have no conflicts. But if you are a paying Red Hat customer with add-ons, and many are, you conflict.
Which goes back to my original issue ...
Marginalizing the paying Red Hat customer in the Fedora Project, putting them clearly at the back-of-the-line, which is only self-defeating for the Fedora Project in general.
I think you misunderstand me. I am doing the opposite of marginalizing the paying Red Hat customer from my perspective. I am trying to minimize any issues that affect RHEL customers.
Many RHEL customers now do not have Add-Ons. I think Add-Ons in my ideal world would be off limits for EPEL. By excluding them from EPEL we cause no problems to any RHEL customers.
Now the argument is made by others, and I think it is a reasonable position to take, that the EPEL community feels that too severely restricts them in a variety of ways including building packages that aren't part of RHEL but which have a dependency that is entangled.
So given the drift that I sense in the EPEL community I am offering compromises that I am comfortable with (of course the EPEL community will make decisions). I really see benefit and no harm at all to RHEL customers if when an EPEL packager finds a dependency in Add-On X for his package he also rebuilds whatever is necessary to satisfy that dependency and includes that in EPEL. The prior suggestion of this likely being a rebuild of the entangled RHEL Add-On package but versioned lower than the Add-On package makes it not conflict with anyone using the Add-On and makes other useful software work.
John