Mailinglist Archive: opensuse-project (194 mails)

< Previous Next >
Re: [opensuse-project] [RFC] - Attempt to build open SLES-based distro
On 2011-09-27 11:29:17 (+0200), Michael Kromer <mkromer@xxxxxxxxxx> wrote:
My idea is to build a SLES binary-compatible distribution
completely supported by the community (and optionally
supported by companies which are willing to do so) - most of
you will probably see lots of similarities with CentOS in this
way - And in fact: This is exactly what I intend it to be.


Another question: how ?

If you want it to be binary compatible with SLES, you will
obviously need to get ahold of the source RPMs of SLES.
So you need a SLES subscription.

Do you plan to just copy over the source RPMs of SLES (including
the SPs and security updates), hack the artwork, and rebuild?

- Yes, I do know about openSUSE Evergreen, but it lacks some
points I've mentioned above like "Enterprise Features",
1-on-1-("binary")compatibility with SLES and the great quality
work by SUSE to get SLES certified by OEM's etc. - and no one
really points its OBS tree to build against Evergreen, it
points it to major channels like SLES11, SLES11SP1, oS11.4,

Not having the many repositories in OBS build against Evergreen
11.1 or 11.2 is indeed an issue. But something that can be taken
care of independently of your approach.

Is it about "LTS" or is it about binary compatibility?
Or both?

If so, why do you want binary compatibility with SLES?

- No, I do not want to work "against" SUSE or anything like

This discussion has taken place already ~ 2 years ago. I took it
up to discuss this matter with Gerald Pfeifer.

The situation back then, and I don't think it has changed, is
that SUSE makes a non negligible part of its income through the
subscription-only licenses -- that is, just the software,
without support.
I don't have numbers, and I don't want to, nor would I get them
;), but if there is a free of charge, binary compatible clone of
SLES out there, it could potentially hurt the income of SUSE (at
least as far as SLES is concerned).

Gerald made it very clear that, because of those reasons, SUSE
would not support such an effort in any way, at all. They
probably cannot prevent it, but you get the picture.

So you might not want to "work against SUSE", but, effectively,
you might actually do so.

Personally, after that discussion and after reporting about it
on the list, I opted out of that initiative because I don't want
to risk a single layoff at SUSE because of something like that.

I'm not saying you shouldn't, you do whatever you want, but you
might want to consider what I wrote above. And maybe check back
with some people (e.g. with Gerald) to have their opinion -- at
least, as long as you don't want to "work against SUSE".

that. The complete opposite is the case: Without SUSE this
would not work well. In fact I really think SUSE also can
profit from a community base around the SLES packages. Take a

Well, without SUSE this would not work well. So why reuse their
work without them having a financial retribution?
You said yourself that the subscription-only licenses are really

look at CentOS - Does it really hurt RHEL? I don't think so,

Ha, you don't *think* so :)

Look, we probably all believe that CentOS is very beneficial to
Redhat. It certainly has been in the past, and people from
Redhat have also been saying that off the record.

*But* there is no proof whatsoever that it has been the case, or
that it would be the case for an "open SLES clone". No proof, no
numbers, nobody can tell.

And, actually, nowadays, Redhat isn't really all that fond of
CentOS anymore.

at least not to a major extent. Lets get the facts straight:
If you are in a corporate environment you _will_ (or at least
you _should_) buy a SLES. Reasons: Support, Updates, Faster
upstream process, tracking, direct contact, etc. But: If you
want to build a steady home system which you do not want to
upgrade less than every year in a major way or you might want
to build a distro fork for special purpose (like for system
integrators, etc.) you (probably) wouldn't want to go with the
fully blown SLES.

Why binary compatibility with SLES then ?

- Yes, I see this as lots of work. Please let me know if you
are willing to help. ;)

Do you believe it is more work than Evergreen ? Or less ?

Don't you think that, instead, contributing to Evergreen has at
least the potential of creating much more synergies, as it is
part of the openSUSE project, on the same infrastructure as the
rest of the project (build.o.o) ?

I know very well that the current situation of Evergreen is not
all that great, because there are barely any people who are
contributing to it (and kudos again to Wolfgang).
Why would that be different with a fork of SLES ?
Why not, instead, try to revigorate Evergreen and contribute
there ?

If you create a fork of SLES, you will not be able to use, and you probably won't be able to even _link
to it.

So how does that increase chances of having the packages that
currently aren't built for Evergreen being built for that SLES
fork ?

-o) Pascal Bleser
/\\ -- we haz green
_\_v -- we haz conf
< Previous Next >
Follow Ups