Overlapping packages: Getting closer to a policy

[inode0]

On Mon, Jun 11, 2012 at 12:13 PM, Bryan J Smith <b.j.smith at 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