I find it surprising that OpenSuse doesn't have an LTS version.

A few months back I installed 12.2 KDE, and I have to say it's really impressive, so much so that I voted it above everything else in this past LQ Awards poll.

Looking forward, though, I have to wonder if I'll stick with OpenSuse. Sure, everything works nicely out of the box, but do I want to chance that all my configuration won't cause bugs if I follow the upgrade path? I don't want Plasma to crash / Steam to stop working / whatever simply because there are config file artifacts and incompatibilities remaining from older packages. I also don't want to start from a clean install, as I do a lot of customization after installataion that I simply don't wish to do every 1.5 years.

Does anybody else feel this way? Has anyone else followed the upgrade path a few times, and have some experience to share with it? It's running on my main workstation at home, and I would prefer not to go back to Kubuntu LTS...

Does anyone know why OpenSuse doesn't do an LTS build at all?

The choice would be to use the Suse version of enterprise linux.

In case you're unaware of it, openSUSE Evergreen might suit your need in this case? See link below for more info.

openSUSE Evergreen

2 members found this post helpful.

Awesome... I actually completely forgot about the Evergreen effort. I came across it back in the day when 10.3 was way past EOL.

I also still have my openSUSE 12.2 running and asked in the German forums where the upgrade paths work well. One told me that he migrated two PCs and one laptop sucessfully to 12.3 but one the other hand I have seen various other postings which mentioned that the update didn't work so well. I have been recommeded to use 'zypper dup' in Runlevel 3 without the X-Server from the person whose updates went well.

I am still a bit undecided too and it feels like a big step.

OK, we have to be completely clear about what you mean by 'the upgrade path'.

There are three major ways of doing something that gets called 'an upgrade'. You could blow everything away, do what is effectively a clean install and restore (selected) stuff from your duplicate back-ups. Most people would call this a clean install, but it depends what you pull back from your backups; if you pull back many dot files, then it isn't really a clean install, but it isn't what most people would call an upgrade, either.

Secondly, you could blow everything away except /home, and install over the top. Mostly this happens if you a separate /home partition and you re-format everything other than /home as part of the install, although you probably come up with other ways of doing this. Many people refer to this as a 'clean install', but if you try it, it is clearly nothing of the kind. Many apps have some kind of 'magic' knowledge of their previous settings, so there is clearly stuff being preserved from previous installs.

Thirdly, there is the zypper dup (or, possibly change your repos over and use yast, if you want to be adventurous) method that is only supported from one version to the immediately subsequent version.

The major (in the sense of time-consuming) problem that I have on a version change is sorting out kde again. My experience is that, even on minor kde upgrades, if you keep .kde (.kde4, actually) from one version to another, you are asking for trouble (and that request will be fulfilled, even if not immediately), so I accept that and blow .kde away on any kde upgrade and start again from a clean .kde. This takes some time, but I find it better than working with a old .kde and finding out after a couple of months that mysterious little bits of kde don't work properly and having to blow .kde away anyway, because its the only way of making progress.

So, I'd say that the biggest part is setting up kde again, but that you have to do that anyway when you upgrade kde, or risk wasting more time on problems that only arise because the . file didn't originally line up the version of kde itself. Everyone else's mileage may vary. And, anyway, I have a set of post-install notes that I can follow that largely get me there, based on whatever I did last time.

That said, if I were administrating hundreds of workstations, I can't begin to describe how much of a pain this would be. Totally impractical. I'm guessing Suse would direct me to SLED, for example, but I don't know what real advantage that would offer in terms of post-install configuration.

Certainly it is the case that you would have to do it less often, but it would still be a total pain when you did have to do it.

Because it would cannibalise the market for SLED?

About Evergreen. Just a fair warning that it might not always be as "green" as one thinks.

I have some openSUSE 11.4 systems going on Evergreen. Much more reliable than openSUSE 12.3. And possibly a bit faster too.

BUT. After a while there came up an update of bind from the Evergreen update repo. I let it update and WHAM!... it totally minced the bind installation including configuration and master files. So i had to downgrade bind. Second choice if a downgrade would have failed would be reverting to disk image snapshot backup.
But a downgrade and an hour of reconfiguring and checking did the job.

So, Evergreen can potentially be as disruptive to your system as going with the "bleeding edge" openSUSE 12.3 with all its faults.

The issues with openSUSE from ver. 12 has made me look into alternatives. And for me the main alternatives seem to be CentOS and OpenBSD. It of course depends on what you use the 'puters for.

Since I was looking for a KDE distro (preferably rooted in Debian, with which I know decently,) but one that won't FORCE me to install it and force remove the other to keep the system from becoming a sprawling mess, I was interested in anyone's thoughts on it. I'm MORE attached to KDE default desktop than to Debian derivative.

Slackware =LTS?

(This is a 2013 thread.)