How do package managers track the installed files?
Suppose for example I install a .deb package that has no dependencies, and the corresponding program includes some self-update feature (or the documentation asks users to do something like sudo foo-prog self update periodically). Later I want to uninstall the package.
How does the system know what files to remove?
What happens if the program's files have been modified or removed, or if new files have been added to those directories, since installation?
Is this different for different distributions (and thus package managers)?
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
For dpkg, the backend for apt on Debian based distributions, checksums for files belonging to installed packages are stored in two places.
First, checksums of all non config files are stored in per package .md5sum files in /var/lib/dpkg/info/.
For example, /var/lib/dpkg/info/apache2.md5sums contains:
61e049e425ec181a32827c78188a5ad1 usr/lib/systemd/system/apache-htcacheclean.service
df833b11ee47d4fdc9a46eef865527e6 usr/lib/systemd/system/[email protected]
fad8b9c1c85cb90821faa328d276f98a usr/lib/systemd/system/apache2.service
2cc4631beab008ebec7beccd0fecd201 usr/lib/systemd/system/[email protected]
42e0c758cfcaa9f9db04e3bd8f51f2b1 usr/sbin/a2enmod
a833732e71d6f7bb55e8bc51158738bb usr/sbin/a2query
014cda6cb0c78b56e8d38f0f9d590136 usr/sbin/apache2ctl
[...]
Second, checksums of the config files are stored in /var/lib/dpkg/status.
Example excerpt:
Package: apache2
[...]
Conffiles:
/etc/apache2/apache2.conf 354c9e6d2b88a0a3e0548f853840674c
/etc/apache2/conf-available/charset.conf e6fbb8adf631932851d6cc522c1e48d7
/etc/apache2/conf-available/localized-error-pages.conf f542d267bfce7815f9453eb1476e5f73
[...]
If the checksums do not match when updating a package, depending on settings and environment variables, the files are either replaced with a backup of the current content, left alone with a new file with the new content, or the user is asked on how to proceed with the file.
Files that have been modified outside of the package manager are usually left alone when uninstalling a package. The same goes for directories that belong to the package, but aren't empty after all files belonging to the package are removed.
0 comment threads
Your question refers to a scenario in which software is installed by a DEB package, but also includes the ability to update itself independently of the package manager. This is very unlikely to work well, and in my experience is exceedingly rare. Software is either installed as a DEB (or RPM etc) package, or it is installed with its own built-in update mechanism, or it is installed via FlatHub, Snap or other packaging systems¹.
Trying to combine self-update with DEB packaging is likely to lead to some problems, depending on how the self-update works:
- The DEB package installs the software to system-wide locations such as
/usr/binand/usr/sharewhich are not writable by ordinary users. As a result, the built-in update mechanism fails because the user running the software does not have the necessary permission to replace the executable and other files. The self-update might succeed if the software is run with root privileges, but running arbitrary software as root is not generally recommended, and might cause other problems (such as writing data files that are not readable by non-root users). - In order to avoid the permissions issue, the self-update mechanism installs new versions to a different location than the original DEB package, such as under
$HOME/.local. At this point, the DEB package is largely worthless because you're actually running a completely different copy of the software in a different location. Uninstalling the original DEB will not uninstall the newly-downloaded copy, because the package manager only removes files that were listed in the original package, and does not touch anything in user home directories or other locations. This could lead to a very confusing situation where you upgrade or replace the DEB and find it makes no difference to the version of the software you're running. - Self-update is a separate tool which needs to be run with root privileges (as in your example:
sudo foo-prog self update). This might work, but as the answer by GeraldS explains, any files added or modified by the self-updater will not be tracked or uninstalled correctly by the package manager, which means you've lost all of the benefits of using a DEB package in the first place.
At this point I can't actually think of an example of software that tries to combine DEB packaging with self-update in this way. Even software that normally updates itself on other platforms (e.g. Discord) requires you to download and install a new .deb if it was installed via the package manager on Linux.
Software that is installed via a DEB and then downloads (and updates) extensions does exist — Visual Studio Code being a notable example. In this case it's doing a variation of item (2) above: the core executable can only be upgraded by installing a newer .deb, but the extensions go into $HOME/.vscode/extensions and can be updated within the software.
¹ It's perfectly possible for more than one distribution or packaging option to exist for the same software, but typically you would pick just one of them for the actual installation.
1 comment thread
Homebrew has different commands for brew uninstall {package} to remove the executable(s) versus brew zap {package} which further performs arbitrary extra cleanup steps specified by the formula.[1]
The zap steps are usually deletion of user data and caches, letting a user decide between just removing the application files or explicitly purging their history.
Here's the zap stanza for Firefox:
cask 'firefox' do
# ...
zap trash: [
"/Library/Logs/DiagnosticReports/firefox_*",
"~/Library/Application Support/com.apple.sharedfilelist/com.apple.LSSharedFileList.ApplicationRecentDocuments/org.mozilla.firefox.sfl*",
"~/Library/Application Support/CrashReporter/firefox_*",
"~/Library/Application Support/Firefox",
"~/Library/Caches/Firefox",
"~/Library/Caches/Mozilla/updates/Applications/Firefox",
"~/Library/Caches/org.mozilla.crashreporter",
"~/Library/Caches/org.mozilla.firefox",
"~/Library/Preferences/org.mozilla.crashreporter.plist",
"~/Library/Preferences/org.mozilla.firefox.plist",
"~/Library/Saved Application State/org.mozilla.firefox.savedState",
"~/Library/WebKit/org.mozilla.firefox",
],
rmdir: [
"~/Library/Application Support/Mozilla", # May also contain non-Firefox data
"~/Library/Caches/Mozilla",
"~/Library/Caches/Mozilla/updates",
"~/Library/Caches/Mozilla/updates/Applications",
]
end
-
"Formula" is Homebrew's term for the code that specifies an installable package. ↩︎
0 comment threads
0 comment threads