Overlapping packages: Getting closer to a policy
Niels de Vos
devos at fedoraproject.org
Mon Jun 11 15:10:12 UTC 2012
On Mon, Jun 11, 2012 at 1:34 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> Niels de Vos <devos at fedoraproject.org> wrote:
>> 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,
> Why not just use the add-ons? Especially when they have clearly been
> in Advanced Server, AS and Advanced Platform and, therefore, EL
> Rebuilds? Why does EPEL have to now ship them, causing yet another
> set of conflicts with both Red Hat and EL Rebuild stacks?
Advanced Server contained the High-Availability bits, hence these
packages could not be included in EPEL. But, it was okay to have
(Build)Requires on the HA packages in EPEL.
My suggestion was to keep it this way. The difference is that Advanced
Server is not available any longer, and RHEL-6 introduced Add-Ons. I
think we can still see the Add-Ons as components of the RHEL Server
subscriptions. Not everyone who uses EPEL, had access to the HA (and
similar channels), that does not change with the Add-Ons. If someone
wants to use RHEL and packages from EPEL that require certain Add-Ons,
requiring a subscription (with access to these channels) makes sense
to me. If RHEL-clones provide all the requirements (like they probably
did already), they won't be affected either.
I am not al all not suggesting that EPEL starts shipping all the
packages from all the Add-Ons. I am sorry it came across like that.
Personally I see all the Add-Ons (from
as part of a RHEL Server installation, and do not like the idea of
having the same (and potentially conflicting) packages from EPEL.
More information about the epel-devel-list