I agree.  However, when I examine the log of which packages were 
replaced (I mean that the files associated with major release N were 
fully replaced by those of major release N+1 -- however, log and end 
user configuration were retained, such as the list of users, passwords, 
etc.), I find that all of the system files, including the glibc, etc., 
that is used by the kernel and other "essential" system components, were 
replaced.  Other than a reformat of the partitions that hold the 
"system", how does this differ?  Admittedly, the mechanism does not 
allow the transition from an ext4 file system to a XFS file system, but 
otherwise, "all" of the "system files" are replaced by those from major 
release N+1.  Evidently, those hardware, etc., drivers that have 
multi-release kernel compatibility were not changed, but those drivers 
that do not were changed.  Only after the running OS had replaced the 
systems files and the system rebooted, did the N+1 OS run.  After the 
N+1 OS was running was it requested to allow removal of those system 
files that had not been overwritten (presumably to add to the available 
disk storage capacity).

What am I missing?

On 12/22/20 6:44 PM, William R. Somsky wrote:
> Truthfully, I *prefer* a full OS wipe-and-reinstall periodically.
> 
> (Note: I'm saying an *OS* wipe-and-reinstall. I always dedicate one
> partition to the OS itself and maintain any local/user data elsewhere.
> I find the idea of storing user files under /home on the root partition
> abhorent now that we have disks large enough that we can create separate
> partitions without having to nickle-and-dime the storage allocations.)
> 
> There are just too many "crufties" that can be hidden away in a
> continuous-upgraded system for me to be fully comfortable with them.
> Things that have been tweaked, stored, tested, backed up, squirreled
> away and/or just plain forgotten.
> 
> And let's face it, doing a full *planned* reinstall of a RedHat-based
> system (or that of any other Linux variant, I presume) is not
> prohibitively difficult. Compare this with a reinstallation of Window:
> do the initial install, reboot, wait for updates, reboot, wait for more
> updates, reboot, wait for more updates, ... ad nauseum.
> 
> If one is considering the effort needed to maintain the configuration of
> various bits of software, the unix philosophy of text-based configuration
> files (though systemd may endanger this) means that one can save a backup
> of these files and diff them or just use them for reference to reconfigure
> the system post-reinstall.
> 
> 
> On Tue, Dec 22, 2020 at 10:44:55PM +0000, Dave Dykstra wrote:
>> 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
>