2

I recently have migrated from Scientific Linux (SL), a RHEL derivative distro, to Ubuntu LTS. This was necessitated by there being no SL 8, and I have been posting to the SL list (a much more freeform approach than used by Canonical for these lists) my observations on Ubuntu LTS versus SL (both "enterprise" or "stable production" distros -- not enthusiast semi-beta distros). One significant difference was an upgrade from 18.04 LTS to 20.04.1 LTS -- this was done in place, without any requirement to reformat the system drive (assuming that there was adequate storage space, and there was). For a similar major release upgrade on SL, one has to reformat -- thus, I would remove the drive containing SL major release N, install a new drive, install SL major release N+1, and then copy back from the removed disk any non-system directories, such as /opt, /usr/local, and much of /home . This procedure is not needed with an Ubuntu LTS major release upgrade. However, there was a claim made on the SL list that the "Debian philosophy" of upgrade-in-place leaves a system that contains SYSTEM (not non-system) executables that are not the same as would be from a fresh install of the "upgraded" Ubuntu system. That is, the system files of 20.04.1 LTS after upgrade would not be the same as if 20.04.1 were installed on a new drive. Is this correct? Does the Ubuntu (Debian) upgrade-in-place leave system "junk" about? I am not referring to configuration files in, say, /etc that have specific configurations for specific utilities -- I need these to be retained in so far as the functionality is available in the upgraded major release. I have read

Is a clean install better than upgrading?

I am not asking for an opinion -- I am asking for detailed information as to the specifics of the differences between a clean install of LTS major release N versus an upgrade-in-place of LTS major release N-1 to N. I assume that there will be an URL or other documentation to answer this question, in addition to the responses that (hopefully) will be posted.

Yasha Karant
  • 961
  • I fear you'll only get opinion related, as most of us don't use a pure Ubuntu 18.04 LTS system when we upgrade; we add other packages to it, often from various sources, meaning we're outside of the QA-tested upgrade path. I release-upgraded my current box every 6 months, it has almost nothing outside of Ubuntu repositories installed (some test packages only which became official packages), yet know it contains junk prior prior releases that I won't see on clean QA-test installs of the same release. – guiverc Dec 25 '20 at 05:58
  • I'm not aware of any URL/doco - but it won't relate to 3rd party packages which is key to the issue, and a HUGE reason why there is crud left. Testing involves only packages included on ISOs (ie. released packages), which isn't how most people use their machines.. crud from those packages gets noticed in QA-test release-upgrades, but 3rd party packages aren't looked for; they're the responsibility of the end-user & not Ubuntu packagers. This is however opinion. – guiverc Dec 25 '20 at 05:59
  • The SL reference was NOT to non-SL-distro packages (NOTE: for SL, one uses supported non-SL repos such as ELrepo and EPEL -- but the contents from these that are needed for SL -- and RHEL for that matter for those who license the binary install for fee -- are incorporated into the LTS distro). For example, I use the Nvidia "proprietary" video/GPU driver that is not part of the base SL distro, but from these other supported addon repos; this proprietary driver -- if allowed as I do -- seems to be part of the base LTS distro (or LTS authorised other supported repo). – Yasha Karant Dec 25 '20 at 06:16

1 Answers1

5

The Debian (dist-upgrade) and Ubuntu (release-upgrade) methods of migrating-to-the-next-release-without-formatting should not leave extraneous files scattered about your filesystem.

Debian has spent 25 years ruthlessly improving package quality, and it's very good. The Debian Archive Admins will reject and delete packages that fail to meet standards or make systems unstable. The standard for deb packages is that the package manager should remove all traces of a package, returning the system to a state similar to before the package was originally installed.

Generally, if you discover "junk" files left behind, that's a bug -- please file a bug report!

Also, if you discover a package that leaves cruft behind, please file a bug report.

There are several exceptions to the expectation of clean removal:

  • Your data in /home, which the package manager will never, ever delete.
  • System configs and settings in /etc. (use --purge to delete these)
  • Temporary files created by running applications, like PID files in /run, lockfiles in /var, and temporary files (mostly) in /tmp. These should be cleaned up by the application upon exit. If not, please file a bug report.
  • Persistent files created or modified by applications, like logfiles or caches in /var. Some will be deleted upon uninstall (caches), others won't (logfiles). If you have manually modified or added your own customizations, the package manager might not remove your file(s).
  • Packages from somewhere that's not in the official Debian Archives or Ubuntu Repositories may-or-may-not meet the standards, and might indeed leave cruft laying about. You likely know better than to install random debs from the big, dirty internet already.
user535733
  • 62,253
  • Thus, if I fully understand what user535733 has posted, the commentary concerning the philosophical differences between the EL and LTS approaches to major release deployments -- that DEB/LTS major release upgrades are not as satisfactory as a clean install (essentially required by SL) is fallacious. A LTS major release production upgrade (e.g., to 20.04.1 LTS, 20.04 not being an allowed production upgrade path from 18.04.x) is the same as a clean install plus "manual" editing of configuration files (e.g., re-deployment of such from an archived disk, as I did in SL major release upgrades). – Yasha Karant Dec 25 '20 at 08:15
  • As for the safety of "unknown" packages (.deb in LTS, .rpm in SL), my understanding is that -- short of compromise of the site -- major add-ons, such as VMware Player, VirtualBox, Calibre (that specifically warns against distro versions as these often are obsolete compared to current production), Mozilla, Thunderbird, TeXstudio, and the like, generally are safe. Does LTS have a "warning list" of possibly dangerous .deb files? On the SL Users List, such questions were posed as to specific "packages" with answers from reliable, experienced users (not enthusiast amateurs). – Yasha Karant Dec 25 '20 at 08:24
  • Sometimes there are fundamental changes, such as the move to systemd. Or ubuntu's introduction of the netplan.io system of network configuration. An in-place upgrade may maintain the old configuration if it is still supported. – Siep Dec 25 '20 at 16:32
  • The same issue arose with systemd on SL. However, there is a "professional" users list on which the matter was discussed, and several correspondents established the morphism -- as possible -- between the previous "method" and systemd, although I do not recall an "automatic" translator. When this sort of thing happens because of "fundamental" changes in Linux, does this forum provide similar assistance, or are there "automatic" tools? In speaking with colleagues who used supported SuSE SLES, SuSE staff assisted with the transformation. Does Canonical -- for paid support -- do the same? – Yasha Karant Dec 25 '20 at 19:10
  • "warning list": Don't confuse packages with the sources that provide those packages. All packages in the official Ubuntu Repositories are "safe" and properly built to Debian standards. We don't check (or warn) about any package from any other (non-Ubuntu) source or PPA. Upstreams can recommend using their builds for their own (valid) reasons, but that doesn't mean the Ubuntu builds are junk (they are not), nor does it mean that the upstream builds confirm to Debian standards (some do, some don't). – user535733 Dec 25 '20 at 20:08
  • The usual tradeoff for most folks is that upstream-built (non-Ubuntu) packages tend to be newer, but sometimes offer less complete integration into the Desktop environment, or the packages sometimes cause file or version conflicts. Conversely, official Ubuntu packages tend to be somewhat older, but their integration with the Desktop environment and their fellow packages is top-notch. – user535733 Dec 25 '20 at 20:13
  • To a large extent, integration is less of an issue than repair of software defects (from the application source developer/s) and increased functionality (e.g., vendor X has just introduced encoding/file format Znew, and the previous application release cannot handle Znew, but the latest production release does -- and because of market penetration or control, most users with whom one must interact are "now" providing files in Znew -- and vendor X does NOT supply, even for fee, any version for Linux -- only the Linux non-vendorX-applications can handle "Z" files under Linux without using a VM). – Yasha Karant Dec 25 '20 at 21:36
  • @user535733 Are you sure you mean "idempotence"? Both in math and official Debian best practices and policy, an idempotent operation is an operation for which the result of applying it twice is the same as the result of applying it once. I'm hoping Debian does not also use "idempotence" wrongly to mean what you mean by it here, but either way, I think this answer would be improved by links to official sources. – Eliah Kagan Dec 25 '20 at 23:18
  • @EliahKagan you are right. Big edit. Thanks for helping to improve the answer! – user535733 Dec 25 '20 at 23:31