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
