Overlapping packages: Getting closer to a policy

Bryan J Smith b.j.smith at ieee.org
Mon Jun 11 18:38:32 UTC 2012

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 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?

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.

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.

> 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

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.

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 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.

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.

#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.

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

Or at least have an user/sysadmin have to tap an EL Rebuild, knowingly
that they have.

Bryan J Smith - Professional, Technical Annoyance

More information about the epel-devel-list mailing list