On 2011-09-27 11:29:17 (+0200), Michael Kromer
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.
Why?
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, etc.
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 cheap.
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 build.opensuse.org, 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 ? cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf