[wplug-plan] Why is there no rebuild of SLES?

[Bryan J Smith]

Oh, in case people bring this up ...

As of RHEL6, Red Hat no longer releases kernel SRPMS with the full
"patchsets" and other "patches" to the upstream kernel base.  This did
not affect CentOS at all, who strives for 1:1 bitwise compatibility,
despite a lot of demonizations in the media.  I.e., even the CentOS
maintainers came out and explicitly stated it affected them none.

This was largely done against downstream, for-profit, _commercial_
vendors who add their own patches, while leveraging all of the
sustaining engineering Red Hat does on (up to) 10+ year old kernels
that have long been abandoned by the Upstream.  I.e., It forced these
downstream, commercial-focused entities to make similar investments,
as Red Hat has, into the kernel and related, core library maintenance.
E.g., Oracle has their own, internal tree for its Unbreakable
Enterprise Kernel (UEK), and no longer has an easy way to leverage all
the various backports and other patches that Red Hat previously and
inherently self-documenting piecemeal patching approach.

As a nice side-benefit, there are now more people at Oracle
contributing to the Upstream as a result.  That's always the great,
side-benefit the community receives when you have to have people in
your organization tracking changes and maintaining them on an older
release -- they tend to find issues, contribute fixes and even suggest
and contribute improvements and other features.

- bjs



On Wed, Feb 11, 2015 at 5:02 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> AndOn Wed, Feb 11, 2015 at 12:02 PM, John Lewis <oflameo2 at gmail.com> wrote:
>> I have a question to all of you Suse fans out there. Why is there no
>> rebuild of SLES similar to the RHEL rebuild called CentOS?
>
> From Day 1 Red Hat released easy-to-rebuild Source RPMs (SRPMS) for
> Advanced Server / Enterprise Linux (RHEL), including the initial
> add-ons for Clustering and other solutions.  SuSE AG did not, prior to
> the Novell acquisition.  Easy-to-rebuild SRPMS release is not required
> to meet the requirements of the GPL, just availability of source.
>
> Now since the Novell acquisition, there are now rebuilds of SLED/SLES
> for "black box" solutions, since Novell full open sourced YaST and
> other components post-SuSE AG acquisition, including easy-to-rebuild
> Source RPMs (SRPMS).  But it's never reached that "critical mass" for
> "general" consumption, other than for some blackbox solutions.  Beyond
> that, even VMware has stayed with RHEL kernels as their helper-host OS
> (e.g., inside of ESXi), because Red Hat's kABI is published and much
> longer-term.
>
> E.g., no one but Red Hat maintains 10+ years of kABI, and even most
> long-term releases rebase every few years, even mid-release sometimes.
>
> Red Hat Legal also pro-actively engaged several of the projects and
> advised them on where they could improve things to avoid the trademark
> issues, and many of the projects.  Over time they built good
> relationships leveraging such advisement.  I.e., despite a lot of the
> demonizations to the contrary, especially early on from CheapBytes
> when Red Hat had some real issues with Sun abusing their trademarks
> (to the point Red Hat Support was getting calls from Sun customers,
> especially for Cobalt units), the good relationships were built
> downstream from Red Hat, including Legal.
>
> Unfortunately, by 2013, the CentOS project was so far behind building
> the various add-ons for RHEL, that it was difficult to get
> interoperability with RHEL systems that had any but the basic add-ons.
> Many of the Fedora Project Extra Packages for Enterprise Linux (EPEL)
> package releases, which CentOS relies on, are newer than the RHEL
> add-ons, and have compatibility issues.
>
> E.g., this was my #1 issue by 2012, and forced me to end usage of EPEL
> at many RHEL userbases.  I know I'm not alone.
>
> So to start 2014, Red Hat hired some of the CentOS maintainers as
> full-time employees, while they continue to work 100% "over the
> fence."  I.e., anyone who uses the term "same umbrella" should really
> watch that phrase.  But yes, Red Hat and CentOS have a "partnership,"
> including some CentOS maintainers -- who work 100% on CentOS, and do
> *NOT* have access to Red Hat build systems -- being very much involved
> with "catching" what comes "over the fence."
>
> The goals of the "partnership" include "keeping up" with the various
> release cycles, add-ons, etc... to improve compatibility and
> availability.  E.g., Red Hat Enterprise Virtualization (RHEV) is a
> biggie, among others.  I.e., most people complain KVM is "hard" or
> "doesn't have features" and don't know RHEV-H ~ ESXi while RHEV-M ~
> vSphere, including a "guest driver disk" that must be loaded.
>
> And that's just one example of an entire product add-on that is
> overlooked for those who just do a basic "RHEL" install.
>
>
> --
> Bryan J Smith - http://www.linkedin.com/in/bjsmith



-- 
-- 
Bryan J Smith - http://www.linkedin.com/in/bjsmith