Overlapping packages: Getting closer to a policy

[Bryan J Smith]

Toshio Kuratomi wrote:
> * Set expectations appropriately for users of EPEL for what they can rely on
>  as being protected and what is not

I appreciate the continued efforts, and I want to hammer this one
home.  Expectations are the continuing key.  Conflicts will happen,
things will change, and there will never be a way to completely
mitigate those.  But changes in the expectations should rarely happen.

I think it's the reason many things keep coming up over and over.

inode0 wrote:
> HA, LB, and Resilient Storage are channels called Add-Ons that require
> additional subscriptions (I'm not sure about the virt channels there).
> Could we be looking here at what comes with some "developer"
> subscription of some sort maybe?
> This has some hints about which Add-Ons require more than a basic subscription.
> https://www.redhat.com/apps/store/add-ons/

I've sat on this a bit, but feel it's time to try "another direction."
 It's these continuing comments that keep me literally "scratching my
head."  I hope it makes more sense from this, "alternative
perspective" ...

It's not just the fact that Advanced Server, AS editions and Advanced
Platform bundles have always included these, as a full, integrated
stack, and they were avoided in EPEL from Day 1.

It's not just the fact that most (virtually all?) "Enterprise Linux
(EL) Rebuilds" have also built and shipped these, also offering a full
stack.

It's the fact that some have the view that instead of choosing one (1)
of these two (2) "well integrated" options:
A.  Red Hat base channel + relevant child channels, *OR*
B.  EL Rebuild that includes the relevant child channels

They think this is a good idea from a "well integrated" standpoint for
building:
C.  Red Hat base channel + EPEL options for child channels instead of
Red Hat ones that were never, previously in EPEL (because they are,
and have always been, in both "A" and virtually always "B")

To me, "B" is an outstanding, community option that many "EL Rebuilds"
strived for bit-for-bit compatibility, have done well, and there's no
reason they shouldn't continue to do well.

And looking at "A", if the idea is to build on actual Red Hat, then
the entire Red Hat stack should be used whenever possible, especially
for the AS/AP lineage that has always been the case.

What I don't understand is why people want to look at "C" at all for
purposes of build.  It should either be to get the channels from Red
Hat, or leverage an EL Rebuild in my view.  To change this would be to
introduce a lot of issues for both types of users.

And yes, that's without even looking at it from Red Hat's support
standpoint.  It just doesn't make sense to me for EPEL build or
development reasons at all.


--
Bryan J Smith - Professional, Technical Annoyance