On Sat, May 26, 2012 at 12:37 PM, Bryan J Smith <[email protected]> wrote:
> Which were always part of the "AS"/"Advanced Platform" entitlements, > and rebuilt by most "EL Rebuilds," from virtually day 1. And these > have not been allowed under the past EPEL guidelines from day 1 as > well, unless I am mistaken. Perhaps for RHEL5, for RHEL6 they are sold and priced as separate entitlements. Which brings up an interesting point, perhaps we should treat EPEL5 and EPEL6 differently here, but have one unifying policy - anything that you can get as a single line-item with the operating system without extra add-on entitlements (i.e. for RHEL5, that would be AP) is not to be included. If Red Hat decides to change the model with RHEL7 or future, then that gives us flexibility without coming back to this discussion at that time. > So you would suggest EPEL take over this role, and the EL Rebuilds > drop it as well? Not rebuilding the exact SRPM's provided by Red Hat in the layered products, no. However, if someone (who would most likely be the engineering owner of that prodcut at Red Hat, let's face it) wants to put their upstream bits into EPEL, I don't think that there should be policy that stops them from doing that. > Then why isn't that left to "EL Rebuilds" instead of Red Hat's > sponsored Fedora Project when it comes to Enterprise Linux bits? Like I said above, I think that EPEL should *not* just rebuild the SRPM's that are shipped as part of RHEL layered prodcuts, that's not the purpose of EPEL. > Also, what do you believe this does to Red Hat customers who use EPEL? > Or are you under the believe Red Hat customers should not, which has > been suggested prior? Who does EPEL serve? As a large Red Hat customer, I use EPEL - i.e. in pulling packages from it internally and cherry-picking those that I want. If you just want to enable the EPEL repo and are a RHEL customer, you should probably use something like yum-priorities to make sure that we don't override stuff in base RHEL+your entitled channels. > > Does Fedora's EPEL serve as the unified rebuild tree from Red Hat's > SRPMS? Or where is the line drawn? Absolutely not. In fact, I would say that any packages that are submitted to EPEL must NOT be simple rebuilds of SRPMS, and unique NEVRA is a requirement. I would be mighty ticked if identical NEVRA packages to what's shipped in layered products, all of which I subscribe to, started showing up in EPEL, in fact. This is mostly technical on my side, my storage mechanism works based on uniqueness of NEVRA. > And what if Red Hat does? Do you accept such? And who from Red Hat? > And how does that work? If Red Hat does what? In reality, I would think such a request would come from Spot, who I always defer to in matters like this. The request would be something like "stop shipping package XYZ, please" and we would then do that. _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
