Overlapping packages: Getting closer to a policy

[inode0]

On Mon, Jun 11, 2012 at 1:38 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> inode0 <inode0 at gmail.com> wrote:
>> 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.
>
> Actually, many do, just not 1:1 with all base entitlements.  I think
> you're ignoring that reality.  But that's another discussion (one I've
> already touched on prior).

I completely agree that many do. So we don't need to argue about that point.

> I think you need to step back and ask yourself why Red Hat has add-ons
> in the first place?  Why did Red Hat do Advanced Server, AS and
> Advanced Platform at all?

I already have explained why I was told Red Hat has Add-Ons.

> My continued issue is that we want to expense those customers that
> fund Red Hat's sustaining engineering first, and think of those who
> either do not, or to a lesser extent.  That's self-defeating, and I'm
> beating this like a dead horse, and feel I should not.  Really, I wish
> others could see that very, very potent point.

I don't see how this proposal is at anyone's expense. How does it
cause a problem for any paying Red Hat customer?

> Now if there is a case for a package in an add-on to be a library or
> other support "common" to many considerations, then the case should be
> made for that package to be in the "base" channel.  Until then,
> there's a reason why it's in the add-on.

That is fine. People can make that case and if and when it is moved to
base it can be removed from EPEL. No problem.

>> 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.
>
> I just do not think EPEL is the solution here.  I must really be
> mistaken on EPEL's history myself.  I know many others are, so I am
> not alone.  If we are attempting to provide a solution for both Red
> Hat customers and community alike, there must be a line drawn on
> dependencies.

That seems to be what we are discussing, where to draw that line.

> What continues to bother me is that I keep seeing a lot of favoritism
> shown towards those who do not fund Red Hat's additional, sustaining
> engineering efforts beyond base.  I think it should at least be
> _equal_ consideration for those who do.

I don't understand this. Everything I suggest is based on my desire to
not cause problems for *ANY* RHEL customer while enabling the addition
via EPEL of as many useful extra packages as possible.

> The "expectations" on this have been all over the place.
>
> First it was Red Hat customers shouldn't be using EPEL (well then, who
> is EPEL for?).  Then it's just Red Hat customers who only use base
> (well the, who is EPEL for?).  But I've beaten the horse on why they
> are important, and not ones to marginalize.  Now we're really throwing
> a lot of asterisks.
>
> My continued view is that the SRPMS are there, and the EL Rebuilds can
> provide them.  There's even been CentOS Extras and others that have
> shipped add-ons too.  Sure, you can draw a line on add-ons v.
> products.  But a lot of people are arguing the add-ons for
> dependencies, when I keep trying to point out that those customers
> that provide more Red Hat funding will be marginalized the most.

I just do not see how this marginalizes them. It benefits them by
making extra packages available to them via EPEL.

> I really feel like I shouldn't have to point that out.  It bothers me
> that I have to.  Really?
>
>> 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.
>
> If EPEL is to be a concentration point for community and EL Rebuilds,
> then that's what it is.  I'll accept it and advise my clients and
> customers to avoid it.  I just need to have that "hammer comes down"
> and move on.

That isn't the point at all and I can't believe any rebuild of RHEL is
going to tell its users to go get package X from EPEL when the rebuild
can provide it directly (like a library that gets rebuilt in EPEL from
an Add-On channel).

> Otherwise, until the "hammer comes down," I'm just pointing out why I
> think it's self-defeating and will cause various issues for Red Hat
> customers.  Dead horse x10 here.
>
>> 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.
>
> Let's separate two (2) things ...
>
> 1)  EPEL user, from
> 2)  EPEL developer/maintainer
>
> It's very important not to confuse #2 with #1.

It is also very important to not miss the fact that without #2 there is no #1.

> #1 should either be utilizing Red Hat entitlements, or considering an
> EL Rebuild.  That way there are no conflicts for either.  If you start
> including things in EPEL, then the EL Rebuilds will just use the EPEL
> ones, but then that doesn't bode well for Red Hat customers who want
> to fund that additional, sustaining engineering.
>
> But in the case of #2, which I believe you are stating here, it should
> be on Red Hat -- via Fedora Project leaders -- to provide the
> necessary entitlements for add-ons to develop and maintain.  I've been
> lauding this for some time now.  Fedora EPEL developer and maintainers
> _absolutely_ need Red Hat entitlements and it's in Red Hat's interest
> to provide them free-of-charge.

They do provide them and they are included in the current build system
if I understand.

> So let's not confuse #2 with #1.
>
>> 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.
>
> Somehow that really doesn't seem to click well with me.  I can state
> several reasons, but I don't see it working.
>
> At the same time, if the version is different, it will at least reduce
> some of the load on Red Hat services and support when they run into
> such.  I'll admit that.  But it would be nice to eliminate the
> possibility.

EPEL can't solve this problem for Red Hat support. We all understand
the issue. We don't want to cause hardship on support or any other
part of Red Hat's operations. But I think we are past "don't ever
release any package that Red Hat releases anywhere" now. That ship has
sailed.

John