On Mon, Jun 11, 2012 at 1:38 PM, Bryan J Smith b.j.smith@ieee.org wrote:
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 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 ...
- EPEL user, from
- 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