Neils wrote:
The difference is that Advanced Server is not available any longer, and RHEL-6 introduced Add-Ons.
This isn't actually the case. Add-ons were introduced in RHEL5 before RHEL6, and I'm not just talking RHN Satellite and Directory Server. Several EL Rebuilds moved to support them as well.
E.g., Scalable File System (XFS) in RHEL 5.4/5.5+ (Tech Preview/Release).
inode0 inode0@gmail.com wrote:
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.
So you would have Fedora EPEL conflict for those with Red Hat subscriptions, in order to assist those without them? And you would also conflict with EL Rebuilds that include them as well?
That now begs the question if the EL Rebuilds will now just stop building them since they are available in EPEL? If so, now Fedora EPEL becomes the concentrator for EL Rebuilds.
If the packages are truly common, a better pursuit would be to have Red Hat move the packages into the base channel. I have noted that Red Hat has done this mid-release when a case has been made to do such.
inode0 inode0@gmail.com wrote:
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.
So what you're saying is what I said off-list as well. Let's not beat-around-the-bush, and I'm going to be direct ...
We're going to reverse existing policy and reduce the "don't touch" list to the $49-349 Red Hat entitlement offerings. Correct?
People say it's only going to be select packages, but before long, it the entire set. This has already been argued many times on this list as well.
Expectations are extremely fluid here and I see much harm to the entire community-sustaining engineering duality. Many people are arguing the alleged point that Red Hat is "taking away," when it's actually a continued change that is adding more into EPEL, not reducing.
inode0 inode0@gmail.com wrote:
I just don't want to ship things with broken dependencies for RHEL users,
That's going to happen based on the add-on model in general. But as others have put it, in many cases, they are related to the add-ons any way.
If they are not, then there should be a strong case for Red Hat to move them into the base. I would pursue that instead of the intentional conflicts here.
inode0 inode0@gmail.com wrote:
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.
Can you explain this to me? How do we avoid conflicts? Something other than repo preference.
-- Bryan J Smith - Professional, Technical Annoyance