RHN software channels & EPEL

[Rahul Sundaram]

Thorsten Leemhuis wrote:

> 
> Exactly. Not having some libs just because some layered product ships
> them as well could be problematic for EPEL and hurt it a lot.

In this talk to Daniel Riek and see if it feasible to add that library 
to the base product. It won't happen immediately. New packages are added 
only when required in the sync updates which was previously quarterly 
and still somewhat follows that schedule.

Even then some customers consider the changes in between these updates 
large and stick with a older version (ie) 4.2 though 4.4 has been 
released and Red Hat has announced recently a separate support and 
updates stream for that case so packages added in the later revisions 
will be excluded for them. As you can imagine there is a lot of 
complexity in managing all these but you can probably ignore this case 
since customers using this update stream are highly sensitive to changes 
and are unlikely to just pull in packages from any external source 
without commercial support guarantees.
> 
> I'm unsure myself about this one. A *short* version and just a fragment
> of the thoughts in my head: people pay Red Hat for the support, but some
> people might just want the support for the OS, but not for a specific
> software they install. Should we try to force those people into the
> existing model (users nevertheless can just rebuild the Fedora-DS or
> RHEL-DS SRPM) or do we simply offer what we have and let them chose if
> they want payed support or not?

I am all in for providing more flexibility here but I don't really want 
to create more support pains. Since the base product that we are 
complimenting has support has one of the core values this has a high 
priority.

Rahul