On Mon, Jun 11, 2012 at 10:10 AM, Niels de Vos <de...@fedoraproject.org> wrote: > On Mon, Jun 11, 2012 at 1:34 PM, Bryan J Smith <b.j.sm...@ieee.org> wrote: >> Niels de Vos <de...@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 > http://www.redhat.com/products/enterprise-linux-add-ons/#features_availability) > as part of a RHEL Server installation, and do not like the idea of > having the same (and potentially conflicting) packages from EPEL.
The difference is something built with a dependency on HA bits then would just pull in those dependencies from the user's subscription, now they would just have broken dependencies for RHEL users without the Add-Ons. I don't have any objection at all to treating Add-Ons differently than we treat other Red Hat delivered products like Satellites or Directory and Certificate services. I just don't want to ship things with broken dependencies for RHEL users, so I would actually prefer EPEL also ship any dependencies from the Add-Ons that arise in a way to not conflict with RHEL users who already use those Add-Ons. It seems there is a good plan for doing such a thing already. John _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
