On Tuesday 28 March 2017, Richard Brown wrote:
On 28 March 2017 at 17:23, Fabian Wein
The key here is that you and your colleagues update your machines
whenever YOU want. If another guy (your admin) would do this with
your machines a few times per year overnight then you would
probably know what I'm talking about.
We are happy to have control on our desktops and servers by
as our group has no admin and the central adminstration is not
flexible enough for
I'd say _especially_ in science where you
sometimes have to
reproduce results from old papers, etc. it has a lot value for
users that they maintain their most heavily used software by
(gnu-modules/virtualenv/anaconda/whatever). Much better than using
randomly whatever comes with your distro. But to make such local
installations usable/possible you have to give them an LTS distro.
Otherwise their local installation will break on every distro
I have the impression you don't understand. For our desktops we
*don't want* an LTS with most of the time outdated versions. This
is different from servers
and clusters but we sit 40h/week in front of our desktops.
So if you are unhappy with your current mixed
machines, I'm sure you all could have it a lot easier if you all
would use the same LTS distro, plus modules/virtualenv as
You missed the desktops: We have desktop distros (just me with TW)
and LTS on
servers/clusters. Currently we are happy. But I feel you want to
remove a modern desktop distro without replacement.
like "why this is working for you but not
for me" should be more
seldom. Just ask your cluster admin for help or providing such
The reason is currently that either they have to use non-standard
repos or build manually to have the cmake/python/gdb/... stuff that
works for me on TW
or I have to fight my TW because I cannot run the commercial Intel
analyzer due to kernel incompatibilities.
Once again, we *don't want* LTS desktop systems, simply for the
reason that for
our use cases it is good to have newest software. We prefer "newer"
"stable and old" for our desktops.
understanding is that having only TW and LTS Leap would mean
that there is no modern desktop available
most of the time.
Isn't TW up-to-date enough?
It is, but in my eyes not necessarily robust enough for general
broad productive desktop use.
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?
- Release schedule that lags SLE (would only be able
*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.
Moreover if we could agree about 100% SLE base. Then it could be even
easy to provide more than one such addon repo, like Leap-very-stable,
Leap-fairly-stable. In other words "very-stable" would still look more
like 42.1 while "fairly-stable" goes direction 42.3.
These addon repos could be even valuable for regular SLE subscribers as
I guess the actual SLE backport repos have only a small community and
do not provide as many packages as Leap.)
Note I do not think that all SLE packages are always better than Leap. I
just think that the SLE package selection is big enough and fixed
enough to cool down the Leap updaters for more stability if we restrict
ourselves to not break that base.
What use cases would you use it for which Leap
I want a distro where self-built binaries don't break because of
maintanance upgrades. This point is my most important point speaking as
sysadmin. I don't want that my (mostly very advanced) users hate me.
Also I want "source-compatibility", I mean that a software which builds
fine on 42.1 should still build on 42.3. The best test for this is the
OBS repo aleady. It should not be allowed that one packager breaks the
package of another packager. Think about developers using Leap as CI
Would this mean reducing the scope of Leap?
IMHO this would be exactly what I thought Leap is supposed to be.
Moreover I would say this would make the scope bigger.
Regarding the unhappy people who want more the newest stuff. IMO we
should keep an eye of making more packages able to be installed in
several versions in parallel, so that pulling from 3rd party repos is
Would you be willing to contribute to/release
maintain/support such a distribution?
Yes, of course. On the other hand I will not provide any build fix
anymore for current Leap, for example my sbcl package. This is waste of
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org