Why don't they "provide it universally in RHEL?" -- WAS: Thoughts from last meeting

[inode0]

On Fri, May 25, 2012 at 5:36 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> On Fri, May 25, 2012 at 5:45 PM, inode0 <inode0 at gmail.com> wrote:
>> I don't see any reason for them to just remove it from EPEL while not providing it
>> universally in RHEL.
>
> Define "universally"?  I can understand people wondering how Fedora
> will handle details.  That's difficult enough at times.

The context here is important. I am questioning the policy of allowing
Red Hat channel owners a veto power over EPEL maintainers in cases of
a package Red Hat provides for some architectures but not for others.
I don't really see any harm in EPEL providing it for architectures
that Red Hat doesn't provide it for and Red Hat has the choice to add
it to the missing architecture which would in effect remove it from
EPEL. There may be problems I don't see, that is why I asked what
motivated the veto policy.

> ... snip ...

>> As an EPEL consumer I find this all rather confusing.
>
> Actually, it's really been going on all along, well before EPEL.
> Advanced Server, "AS" and "Advanced Platform" (AP) were already
> "layered products."  Several "EL Rebuilds" would build that code.
> EPEL came around and avoid them early on.  But since then, Red Hat has
> heavily expanded that.  It's no longer a half-dozen-plus (6+) child
> channels, it's now up to three dozen or so (~36) if you add them all
> up.

Layered products are not confusing. An EPEL policy of protecting
conflicts with a small subset of layered products is confusing. The
rationale for that choice, the consequence of that rationale applying
to 2 more layered products tomorrow, adds uncertainty to the
consequences of using EPEL. It is much more clear to EPEL consumers if
conflicts with layered products are treated in a consistent manner
going forward.

> ... snip ...
>
>> I don't want to have to know which layered products are protected and which aren't.
>
> Define "protected"?  I think you're looking at that from the wrong
> angle.  I've never looked at Red Hat "protecting" anything.

None of this is about Red Hat. The protected layered products are the
two that EPEL has singled out to protect EPEL users from conflicts
with while allowing conflicts with all the rest of the layered
products.

> And even from the Fedora angle, I don't consider EPEL trying to
> "protect" anything.  EPEL is trying to serve the needs of the
> community of users, customers, everyone.  That's a tall order.  It has
> had its policies.  It will continue to do so.  Red Hat just did not
> ship a lot of components at all, components that many in the
> community, including Red Hat customers, did not have.  EPEL was the
> result and why I tapped it immediately.

EPEL has always tried to protect its users from package conflicts with
RHEL provided packages.

> ... snip ...
>
>> I think I'd rather live with a simpler uniform policy regarding layered products.
>
> Going with your point above, is it really a "simpler, uniform policy"
> for Fedora?

This isn't about Fedora, it is about EPEL users.

> Or are you really inquiring why Red Hat has "layered entitlements" in
> the first place?

No, this only has to do with the effect of package conflicts in
organizations using RHEL, with or without layered products, and EPEL.

> Seriously, I'd rather not dance around the issue, but see a direct
> statement made.

I'm not dancing around anything and find most of this post completely off-topic.

> ...snip ...

John