Overlapping packages: Getting closer to a policy

[Bryan J Smith]

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 at 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 at 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 at 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 at 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