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
http://www.redhat.com/products/enterprise-linux-add-ons/#features_availability
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:
-
http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-purchasing-guide
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
installed.
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?
Cheers,
Niels
More information about the epel-devel-list
mailing list