Overlap policy v20120615

Bryan J Smith b.j.smith at ieee.org
Sun Jun 24 15:49:41 UTC 2012


inode0 <inode0 at gmail.com> wrote:
> Because they either won't build due to unresolved dependencies
> > in the build system in the cases of RS and SFS

I thought Red Hat is providing the necessary add-on entitlements?  If
not, that needs to change, especially since "EL Rebuilds" provide
them.

> or they will build but produce packages that have unresolved
> dependencies at install time in the cases of HA and LB.

Which means there should be a tool (e.g., YUM plug-in) that notifies
Red Hat customers of what entitlements they are missing.  I can see
several approaches where Red Hat could offer this.

> While we do currently have packages in EPEL in this latter category
> I don't think anyone really thinks it is a good situation

Why not?

Red Hat customers should have the option to either:
A)  Assign (or acquire, if necessary) the necessary entitlements, or
B)  Find an alternative, open source option to them (e.g., EL Rebuilds)

I'm for notifying the Red Hat customer when they do not have the
necessary entitlements, instead of blindly doing it for them, possibly
causing them additional support issues.

> and it at the very least contradicts the EPEL note to RHEL6
> users that they need to enable the optional channel to satisfy
> dependencies.

As I've been constantly asking throughout all of these threads ...

How is this any different than EPEL5 or earlier?  Or is it only more
recently that people have started to build against the various -devel
and add-on packages, and are only doing this against EPEL6?

Scalable File System (SFS aka XFS) was added to RHEL5 as well.
Resilient Storage (RS aka GFS2) has been around since RHEL5 too (and
GFS in even earlier).

Am I missing something here?  None of this lineage has changed.  I am
completely open to being corrected.  But as I have shown time and time
again, I've been fairly accurate.

But for some reason, and to use the term you used, "concrete" hasn't
been applied to my replies, despite my research and e-mails
(especially those off-list, which you did receive too).


--
Bryan J Smith - Professional, Technical Annoyance




More information about the epel-devel-list mailing list