Hi Yasha,

Yes this is one of the most significant differences between the Debian/
dpkg/apt world and the Red Hat/SUSE/rpm/yum/dnf world.  It's a
difference in philosophy and it is reflected in the tooling.  There are
a lot more explicit package version dependencies in Debian that makes
this possible.  On the other hand there's a lot less backporting that
goes on there, so there's more instability.  I think that the
requirement of going through extra effort every 5 to 10 years to do a
reinstall from scratch is a deliberate choice in the rpm world.  I like
the relative ease of Debian upgrades, but it does have some
disadvantages too because you end up not upgrading some things.  For
instance I haven't done a fresh install in around 20 years on my home
Debian server, so as a consequence it is still using 32-bit executables
even though the hardware has long been capable of 64-bit.

Fedora releases are much shorter life and I've heard there's a tool
there to upgrade between releases more seamlessly, although I haven't
used it myself.

Dave

On Sun, Dec 20, 2020 at 12:28:56PM -0800, Yasha Karant wrote:
> I just upgraded an end-user laptop workstation from Ubuntu 18.04 LTS to
> Ubuntu 20.04 LTS.  Compared to what is involved in making a major release
> change in SL, this was trivial.
> 
> Because SL (and presumably all EL, perhaps except for some licensing from RH
> for which RHEL will "upgrade in place" -- at least I have read about such)
> requires a fresh install with a fresh format of the hard drive to change
> major releases (e.g., SL 6 to SL 7), I typically purchased a new harddrive
> upon which to install a new major release of SL.  After the partitioning and
> installation of the default SL N+1, I would place the SL N system harddrive
> into an external drive interface adapter, often via a USB connection to the
> running SL N+1 system, and proceed to copy files onto the new harddrive (not
> just /home, but /opt, /usr/local, etc.).  Once copied, some (many?)
> applications that existed in /opt, etc., (not /etc -- English usage, not a
> directory), would then have to be upgraded or older libraries had to be
> installed but not in any way that could interfere with the SL N+1 libraries
> needed by the SL N+1 system.  This could be a complicated and tedious
> procedure, often involving more than one day of work.
> 
> By contrast, going from Ubuntu 18.04 LTS to 20.04 LTS was an upgrade in
> place, over the web (but taking some time because of the limited bandwidth
> we have at home using our ISP).  The only precaution I did was to copy the
> end-user's complete home directory to an external USB harddrive.  I then
> proceeded with the upgrade using one of several web sources for the
> instructions.  The upgraded system boots, and other than a peculiarity in
> getting to one search engine URL from Mozilla Firefox non-distro (stock
> production from Mozilla), everything seems to work as well or better than
> the pre-upgraded Ubuntu. I have not needed to access any of the files on the
> external USB pre-upgrade backup.  During the upgrade, the upgrade utility
> detected that I had edited several system utility configuration files (that
> allowed such actions a root MATE GUI login and use screen, not just sudo
> within an ordinary user MATE screen), and these evidently were the "same"
> between major releases (the changes all seem to have been retained and are
> operable).  The upgraded included the use of the proprietary Nvidia GPU
> video driver and the Nvidia GPU proprietary settings/control GUI application
> (under MATE) that might, or might not, require an upgrade from a
> non-SL-hosted distro for the same type of major release upgrade on SL
> (having done this with that experience during several SL major release
> upgrades).
> 
> I am not using Ubuntu on any server at this time, although I know of several
> sites that do use Ubuntu LTS as a server OS.  However, I am using it on
> workstations because it seems stable and it seems to have an easier "time"
> of enabling "current" GUI production applications that are need for
> composing and viewing files of various types (e.g., TeXstudio) than does SL,
> mostly because of SL using an older c/c++ library that also is used by SL
> ("kernel") and thus not easy (nor safe) to change.
> 
> Take care.  Stay safe.
> 
> Yasha Karant