On 03/29/2017 05:28 AM, Ruediger Meier wrote:
On Tuesday 28 March 2017, Richard Brown wrote:
On 28 March 2017 at 17:23, Fabian Wein
> Rüdiger Meier wrote:
I would like to take this point in the thread to conduct a
theoretical, thought experiment.
I want to make something absolutely clear, I'm asking the below as
'Richard the contributor', not 'Richard the SUSE employee', and what
I am about to suggest should not be taken as an indication that SUSE
are even considering the below.
Would the users and contributors on this list be interested in a 100%
matching SLE-like LTS distribution?
Yes. Though I would say just all _common_ packages should be the same.
(Maybe a few exceptions for branding stuff or other things I don't know
The main difference from Leap would be
- absolutely no divergence from SLE, period
- no additional community packages in the distribution
This "no additional" point is something I don't like as strict, but see
much 1 tool for 1 task. One DE, One web server)
Isn't IceWM also in SLE?
It is but most would argue it is still just a window manager not a full
schedule that lags SLE (would only be able to release
*AFTER* SLE, whereas Leap we can develop it WITH SLE because we're
There would be no guarantee of a release-lifecycle any different from
Leap, because such an idea could rely entirely on the sources made
available to openSUSE via SUSE's contributions to Leap.
If the answer to the above is Yes the follow up questions are
Would you like this in addition to Leap, or instead of?
Leap (or whatever name) could just like an addon repo containing all the
missing 7500 packages which are not in SLE. It should be still
carefully maintained, fixed versions at the first release, updates only
for very good reasons.
Richard didn't suggest this and probably for several very good reasons
here are some. Firstly there will be libraries as an example with
different versions between SLE and Leap, often we are quite happy to
have only 1 version of these libraries so know one has bothered to setup
multi version support. Say we have library A that has version 1.0.1 in
SLE and 1.0.2 in Leap, Now package X that is only in leap will be built
against the newer version of A and as such may use symbols only found in
the 1.0.2 version, running X on the SLE based system will cause it to
crash at startup unless its rebuilt, and supposing we chose to rebuild
it in this special new repo should the build fail because X requires the
1.0.2 version of A who is going to fix it? are you asking all the
maintainers to now start supporting another distro?
I could go onto the fact that this extra repo wouldn't be tested so
would probably contain bugs which would harm our reputation unless
people also step up for testing. I'm sure some others would come up with
other reasons why this wouldn't work and why it would have to be just
SLE with different branding / wallpaper packages.
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B