Overlapping packages: Getting closer to a policy

inode0 inode0 at gmail.com
Mon Jun 11 15:18:43 UTC 2012


On Mon, Jun 11, 2012 at 10:10 AM, Niels de Vos <devos at fedoraproject.org> wrote:
> 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
> 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




More information about the epel-devel-list mailing list