Overlapping packages: Getting closer to a policy

Niels de Vos devos at fedoraproject.org
Mon Jun 11 09:23:22 UTC 2012

On 06/09/2012 12:37 AM, Stephen John Smoogen wrote:
> On 8 June 2012 15:50, inode0<inode0 at gmail.com>  wrote:
>> On Fri, Jun 8, 2012 at 5:16 PM, Stephen John Smoogen<smooge at gmail.com>  wrote:
>>> On 8 June 2012 12:14, inode0<inode0 at gmail.com>  wrote:
>>>> Really confused by this. LB and HA are useful but they are not
>>>> available to everyone who has a basic RHEL subscription currently.
>>> Well they seem to be available to the people who thought they had a
>>> basic subscription. What channels do you see with a basic
>>> subscription?
>> None on this list of Add-On subscriptions.
>> http://www.redhat.com/products/enterprise-linux-add-ons/
>> I'd have to double check what you actually do get because it often
>> includes lots of odd-ball channels.
> Oh cool. That gives us the matrix of what is available with Red hat
> Server. Thanks inode0
> We are building against Red Hat Enterprise Linux Server which comes
> with the following add-ons
> High Availability
> Resilient Storage
> Load Balancer
> Scalable File System
> High Performance Network
> Smart Management

I'm sorry, but this is incorrect. The table at 
lists which add-ons are available for Red Hat Enterprise Server. 
Available here is not 'included', but more something like 'compatible' 
and or supported combinations of add-ons.

The additional costs for each add-on is listed here:

A quote from that page:
"You can add optional functionality to a Red Hat Enterprise Linux Server 
subscription. The following prices are in addition to the price of the 
underlying Red Hat Enterprise Linux Server subscription."

I think it is important to make a difference between add-on (like High 
Availability to Red Hat Enterprise Server) and a product (like Red Hat 
Satellite). IMHO it makes sense to allow EPEL packages with 
(Build)Requires from the Add-Ons, but not from the products. Products 
can/may contain different versions (more restrictions) of packages than 
that are available in the Add-On channels.

Some examples:
RHEL customers that do not have the required add-ons (like HA), would 
have dependency problems for packages from EPEL that require the cluster 
infrastructure. I doubt that these packages are useful without the 
cluster bits. RHEL-clones can provide the add-ons as part of their 
standard distribution, no dependency issues there.

On most (all?) Red Hat Products (like Red Hat Satellite and Storage) 
customers are not supposed to install additional applications. The 
products are mostly contained within their own installation. It makes 
little sense to add EPEL to these servers where a product has been 

Therefore, it is possible to allow puppet, glusterfs and the like in 
EPEL. These packages are part of Red Hat products, and not available in 
the add-ons. The standard Red Hat Enterprise Server can be enhanced with 
non-conflicting packages.

Does this make sense to others as well?


More information about the epel-devel-list mailing list