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

Bryan J Smith b.j.smith at ieee.org
Wed Feb 11 17:02:33 EST 2015


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


More information about the wplug-plan mailing list