I have been going in for a fresh install for two reasons. First is that I keep latest two versions for safety so each time a new version is out I replace the older installation. Second was that data in /Home could easily be reproduced in the newer version.
Now that I have a separate partition holding my data the second reason no longer matters. And the fresh install involves a longish tuning process, downloading additional applications (from Leap repos) I use. Does an upgrade handle all the changes involving Leap repos? I suppose the upgrading of apps from Packman repo will still have to be done separately.
My line of thinking is to delete the older version for example Leap 15.0, backup 15.1, upgrade 15.1 to 15.2 and then recover 15.1 from the back up in new partition(s). Does it make sufficient sense?
I have been doing fresh installs, but for a reason.
Like you, I keep several versions. Right now, I have Tumbleweed, Leap 15.1 and Leap 15.2.
For me, the reason for this is that I start testing early. I installed Leap 15.2 back in February, but I did not begin to use it for regular work until May. That testing schedule pretty much forces me to have both 15.1 and 15.2 installed.
I have tested upgrade (tested in a virtual machine), and it works well.
If I were not testing, then I think the best procedure for me would have been:
Upgrade throughout the Leap 15.x series. Do a fresh install for the Leap 16.x (or whatever it will be called) series.
And a note on “/home”. I have a “/home” on one of my installed systems (currently Tumbleweed). On the other systems, I mount that as “/xhome”. This leaves “/home” as part of the root file system. I then use symbolic links so that most of “/xhome” becomes readily available in my home directory. But configurations are kept separate. So “.config” and “.local” are different for each installed version. This avoids conflicts.
When I first installed Leap 15.2, I then copied “/home” from Leap 15.1 to Leap 15.2. That initialized configurations and created the needed symbolic links. But, after that initial copy, the configurations on 15.1 and 15.2 are separate.
Now that I am mainly using Leap 15.2, I am mostly ignoring Leap 15.1. But I still regularly update Tumbleweed (once every two weeks) and occasionally boot into that system.
I’d like to see a detailed example of nrickert’s use of symbolic links. I wouldn’t want my root filesystem to be encumbered by the vast quantity of data in ~/.mozilla/ with multiple browser versions and profiles to go with each, or ~/.config/[chromium,falkon,et al], or ~/.moonchild productions/, or any other web browser, or maildirs.
% ls -l .mozilla
lrwxrwxrwx 1 rickert users 28 Jun 22 2017 .mozilla -> ../../xhome/rickert/.mozilla
Mozilla software is usually well designed. As long as the firefox version is the same, it can be shared with different system versions.
But for chromium, I keep them separate. I don’t actually use chromium a lot. It is the browser that I use when I am doing something that requires being logged into google.
I’ve found Chromium to be superior for exactly one task: Google Maps, especially GPU-accelerated rendering of 3D map objects and street view.
For everything else, I use SeaMonkey. I can recommend version 2.53.2, it’s been stable beyond reproach as well as up to date with recent additions from Firefox and Thunderbird. The single add-on I’ve used recently: uBlock Origin, don’t need anything else anymore.
I really like using SeaMonkey’s developer goodies (from Firefox) and the integrated mail client (with parts from Thunderbird), but also the almost nostalgic Netscape-style configuration dialogs and the integrated HTML editor a.k.a. Composer. It’s nice to manage all those »internetty« things with just one program. Yet, SeaMonkey still is a bit sluggish rendering said maps and street views, hence my one exception for using Chromium.
Makes sense. Only doubt is setting of say 15.0 would now appear as for 15.1 and those 15.1 would appear in 15.2 and those in 15.2 would be lost when next 16.0 is fresh installed. Sorry if it is a little confusing.
And a note on “/home”. I have a “/home” on one of my installed systems (currently Tumbleweed). On the other systems, I mount that as “/xhome”. This leaves “/home” as part of the root file system. I then use symbolic links so that most of “/xhome” becomes readily available in my home directory. But configurations are kept separate. So “.config” and “.local” are different for each installed version. This avoids conflicts.
Do I correctly understand that you create a mount point /xhome in /home of each version and mount the Tumbleweed version /home there? My method of creating a /Data folder under root and mounting a separate partition there does not call for symbolic links. Which is why I chose this route.
When I first installed Leap 15.2, I then copied “/home” from Leap 15.1 to Leap 15.2. That initialized configurations and created the needed symbolic links. But, after that initial copy, the configurations on 15.1 and 15.2 are separate.
Aren’t there differences in the “basic” as downloaded files in different versions? Copying /home from an older version to newer version would affect such files.
My reason to look at upgrade route is to reduce the labour involved in fine tuning the new version and yet retain my older version as it is as a safety measure till the new version settles down! At the moment it appears as choice between “12” of one and a “dozen” of the other!
“/xhome” is a mount point in the root directory. I tell the installer to mount my home file system there (with the expert partitioner), and the installer creates the mount point.
Aren’t there differences in the “basic” as downloaded files in different versions? Copying /home from an older version to newer version would affect such files.
I guess it depends on what you mean by “basic”. What I am copying in that step is mainly “.config” and “.local”.
For Leap 15.2, that means that my KDE desktop started out as configured in 15.1. The desktop software adjusts it from there.
I just did an in place upgrade on one of my Laptops from 15.1 to 15.2
Simply by editing the repos in Yast software repositiories from 15.1 > 15.2
Refreshed
The Update all unconditionally
Went perfectly, as it usually does
