inode0 inode0@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 dependencies.
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 possibility.
Or at least have an user/sysadmin have to tap an EL Rebuild, knowingly that they have.
-- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith