I’ve been using SuSE Linux for 10+ years and love it. I have a highly customized installation running network services many of which I build from source so I can easily control which version I am using and when to upgrade. Many of these builds end up using libraries (and source) distributed by SuSE and I am fine with that. In years past when I would upgrade to a new SuSE release I’d start with a fresh install on a brand new disk on my backup server so that I could get everything working just right before swapping the new disk into the production server. This strategy was reliable and resulted in just 15 minutes or so of downtime. But this process takes forever because I start from scratch each time.
I am now tempted to try upgrading my system rather than building fresh. I will now start with a copy of the running system on a brand new disk which I will then attempt to upgrade. As I’ve read through everything I can find on the process, the chances that this will mostly work are good, but I cannot find an answer to this scenario:
Let’s say I am using version 1.0 of a particular library distributed with openSuSE 13.2 and I’ve buily a custom version of Apache httpd with that version. That version of httpd is expected to “just work” after the upgrade without needing to be recompiled (httpd is an example; the answer here isn’t “just use the SuSE package”). And that should be a good assumption if all the libraries remain intact after the upgrade to 42.1. But what if 42.1 either doesn’t use that library at all or it uses version 2.0 only and decides to remove version 1.0? Will the upgrade process erase version 1.0 of the library thinking (correctly) that no 42.1 packages require it? But deleting that library would break all the other software I built from source that requires that library but has no way to convey that requirement to SuSE’s package manager.
If my fear above is valid, then “upgrade” saves little time for me over “fresh install.” What can I expect? Is there a way to tell the upgrade process not to remove older libraries or their sources if a major version number changes? (Minor versions should be OK thanks to the way libraries are handled in Linux.) I would also be OK with an option that doesn’t delete anything for which there is no direct replacement for (for example, a library upgrade from 1.23.0 to 1.23.3 should remove 1.23.0 since they are both compatible but if it leaves 1.23.0 that is fine too, but an upgrade from 1.0.0 to 2.0.0 should install 2.0.0 and not remove 1.0.0 to avoid breaking my self-built software).
IMHO Upgrades installs work ok for the most part when moving one version and assuming not a huge amount of customization. Moving 2 or more versions in one step can run into problems even with pure vanilla set up. Any program that is also a default program will probably be replaced though you can over ride in the installer. Also note many programs are recommended so may also be reinstalled or updated so you would need turn off recommended in yast before doing any updates.
Moving one step at a time is the recommended path but even that can raise problems. Default packages can change between versions for one thing. Also config file formats/locations may also change
Note that 42.2 is on the verge of finial release in a matter of days now
zypper dup not only replaces packages with the newest ones but removes packages too, afaik updated versions of system libraries are removed during an upgrade the example you used if 13.x used version 1 and 42.x version 2 during an upgrade version 1 will be removed.
I’m not sure about custom rpm’s, files in /usr/local are untouched if your custom libraries are there they will remain.
you could try doing an online upgrade on a 2nd disk worst case scenario you’ll have to reconfigure your system and you would have done that anyway https://en.opensuse.org/SDB:System_upgrade
I’ve stepped away from custom solutions ( self-compiled versions etc ) exactly for this reason. We now have wonderful stuff like openQA ( which does upgrade tests from version X to version Y ), but stepping away from the defaults breaks that. I found I win a lot of time when I stick to the stock distro as much as possible. My 2 cents.
Thanks for the replies. I’ll just give it a try on a copy of the system and see how much of my custom stuff breaks. If it’s only one or two things it would still be a big time saver to go the upgrade path rather than fresh install.
I still think there should be an upgrade option that leaves old *libraries *and their sources in place. I appreciate the comment about just using SuSE packages for the very reason I am raising a concern, but what if I have applications (as I do) that are not offered in the SuSE distribution? If I compile them and they use SuSE libraries and a future upgrade removes some of those library versions (even if replaced by newer ones) my built-from-source software will fail and need to be recompiled. Not a disaster, but not ideal.
Instead of compiling them on your own system, you could use the openSUSE Build Service ( https://build.opensuse.org ) and build packages, By enabling the repos for the openSUSE verions you need, you could at least see if the packages build on the new version. OBS is a bit of a learning curve, but AFAICS it would save time.
Thanks for the suggestion. I’ve heard of OBS but haven’t really looked at it. I may do that after I see how my current approach to the problem turns out.