There are a number of quality of life tricks for Debian that I wish I’d known when I was first learning the ropes. Mostly package management things. But they’re not expressly stated in the kinds of places that a first timer is likely going to see them. Some are dead stupid, but the ‘wrong way’ is still perpetuated to this day by techtubers who pump out video after video without double checking things beyond surface level. Such is the case with apt commands. It is apt, not apt-get. They only keep apt-get around to maintain backward compatibility of shell scripting.
Much I had to discover through trial-and-error or by crawling through forum threads or man pages. Without further ado:
Apt has a builtin for editing the sources file, instead of manually calling a text editor to the sources.list file path.
Keeping a lightweight install, especially when adding the first packages on a newly provisioned system.
apt install cinnamon-core
Extra bonus if you’re using Gnome, for which there is an even more miminalistic metapackage.
apt install gnome-session
apt install --no-install-recommends packagename
It is much easier to add additional packages and dependencies as you find them necessary, rather than to try to remove unwanted things after the fact and risk running up against dependency hell. But if you do find yourself removing things, purge them instead of removing them.
apt purge packagename
This will also rid the system of residual configuration files for that program (except for those in the /home directory).
Add the backports repository to your apt sources.
deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian/ bookworm-backports main
What, you’re not stuffing package management through tor? Well you should.
For the sake of compatibility, some programs need to track upstream releases beyond the frozen stable version. Notably yt-dlp, for example. Apt can query the presence of a package from the backports repository via:
apt search -t stable-backports packagename
Substituting the release name for stable, of course. Installing the package with this same switch will ensure that it follows the backports releases.
apt install -t stable-backports packagename
While unattended-upgrades is great and all, I am more partial to apt-config-auto-update as I have programs I like to check source changes before applying upgrades that can potentially break my boot process. Yes, even the packager maintainers are fallible beings who sometimes make mistakes. This will automatically check for and download upgrades, but leaves the obligation to install upgrades in the hands of the operator.
And before applying any upgrades, it is always good to have resources that one can cross reference before committing to any upgrade.
Additionally, when we rely on human presence to apply upgrades, it’s never a bad idea to have notifications. My own in-house solution already has a way of notifying me but there is package-update-indicator available for those who wish to have a visual reminder.
When something is broken, and you wish to temporarily avoid upgrading it, it is very simple to pass:
apt install --only-upgrade packagename1 packagename2
Leaving out the package(s) you wish to leave as-is. Longer term holds should probably go through apt-mark:
apt-mark hold brokenpackage
And unhold it later once things are in the clear. I’ve saved myself a few headaches on servers this way wherein I wasn’t quite ready to deploy some of my own shoddily written scripts still relying on APIs from previous versions.
I’ve done it, and you probably have too, having installed several development libraries and other dependencies to compile a program that wasn’t in the Debian repositories (or available for one’s CPU architecture!). And long after you’re done building the program, there are now dozens of libsomething-dev cluttering your install. Which ones to remove? Good luck, I hope you wrote each one down!
…Or we can rely on trusty apt-cache and other tools.
Find out what a given package requires before you install it:
apt-cache depends packagename
Or check the dependencies that an already installed package had pulled in.
apt-cache rdepends --installed packagename
If you’ve really created a mess for yourself, there is the handy deborphan tool for finding packages that are no longer needed. No special switches needed.
This will catch things that simply aren’t tracked by apt autoremove. Speaking of apt autoremove, we want to always purge packages, as earlier.
apt autoremove --purge
Resent releases of Debian seem to have apt take care of old installed Linux kernels automatically. But this hasn’t always been the case (or maybe it was just the way I’d previously configured my system). The /boot partition is only allocated several hundred meegabytes by default and can fill up fast if one allows too many kernel versions to be installed. Check the current running version:
We don’t want to go removing the same kernel that the current session has booted on! List all of the currently installed kernels.
dpkg -l | grep linux-image
Apt can be supplied several items to add or remove in batch.
apt purge linux-image-x.x.x-xx-architecture linux-image-x.x.x-xx-architecture
And of course during the addition or removal of any software, we want to make sure that running processes are all using the most current versions. Debian’s needrestart is indespensible and is a crime it’s not included by default (it’s not, right?). needrestart is pretty hands-free as it will automatically run at the end of any apt install/purge/remove to highlight processes that need to be restarted to run with newly installed libraries and dependencies.
While it is possible to simply adjust one’s source file to point to a new release and then run apt full-upgrade, this is admittedly a bit dangerous and could misplace things when going through such massive change. The officially ordained upgrade process is pretty well documented in the Debian release notes for any release version. I’ll summerize it here.
Make sure we’re up to latest point release. (sudo supplied where needed. What, I haven’t been doing that?)
sudo apt update
Check Debian packages for any possible conflicts.
List possible packages originating from outside of Debian repositories and purge them if necessary.
apt list '?narrow(?installed, ?not(?origin(Debian)))'
Clear packages no longer needed.
sudo apt autoremove --purge
Clear the apt cache of previously and partially downloaded packages.
sudo apt clean
Look through old configuration files and remove if necessary.
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
Do you have enough free space?
Change sources to the new release.
sudo apt edit-sources
Disable *-backports repository until after the upgrade and remove proposed-updates section if it is present to reduce the likelihood of conflicts. Disable apt-pinning from /etc/apt/preferences, /etc/apt/preferences.d/
Pull in changes from sources file.
sudo apt update
In some cases, doing the full upgrade (as described below) directly might remove large numbers of packages that you will want to keep. We therefore recommend a two-part upgrade process: first a minimal upgrade to overcome these conflicts, then a full upgrade.
sudo apt upgrade --without-new-pkgs
Continue with the main part of the upgrade.
sudo apt full-upgrade
During the upgrade, you will be prompted about differences between the configuration files being installed versus old configs you may have modified. Prefer keeping existing configuration files, and note them down to merge changes later.
Reboot to finish restarting all services
Finish adjusting apt sources file to re-add the backports repository, if it was previously selected.
sudo apt edit-sources
sudo apt update
List obsolete packages, and optionally purge them.
apt list '~o'
sudo apt purge '~o"
Careful with this! Consider manually removing one package at a time if you’re not sure. Then remove leftover packages that aren’t explicitly declared obsolete from above.
sudo apt autoremove --purge
Like we covered earlier in the Cleaning up one’s system section, check kernel versions, in case autoremove does not handle it.
sudo apt purge linux-image-x.x.x-xx-arch
Admittedly a long and not very layuser friendly process, but certainly worth it for the precaution. Especially if you’re upgrading a Debian system remotely over SSH where breakage can potentially prevent you from reestablishing connection to the newly upgraded environment.
Unfortunately very few of us can enjoy running a system totally free of blobs. I sit here typing this, painfully aware that my AMD graphics adapter requires such a binary. Either that or suffer using Aspeed framebuffer with wayland. Luckily, we can track what non-free parts get installed. Formerly vrms:
Will list out the total installed packages originating from contrib, non-free and non-free-firmware repositories, as well as the overal percentage of your installed system that they comprise.
*Note that in its ideologically driven focus, this tool will mark things like fonts “non-free”, even though we as end users don’t really care what license is attached to it. I just want to minimize the execution of black box code. But that’s for another article.
It’s always the corporate type tech bros from which I hear “Use htop bro! It’s so much better! It has usage lines!” The same archetype who use “Neofetch” to post hardware & system info instead of dmidecode or /proc/*info.
Of course they’ve never read more than a line into the top manpage (if at all) because otherwise they would have found that this feature is in top. It’s just not enabled by default. Save yourself some bloat and just take advantage of what’s already in Debian.
Quick tip using the following hot keys with top running:
m - Toggle memory usage as bar/block graph
t - Toggle CPU usage as bar/block graph
4 - Display CPU usage as per-core
1 - Display CPU/memory usage bar/block graphs abreast
W - Save current configuration to toprc
Activated, in the above order:
There exist additional settings for colors and such. Have a look for yourself.
There are so very many other niceties like using libreoffice-gnome to better visually integrate libreoffice with GTK but this has already drawn on far longer than I intended. Maybe these QoL tips merit their own individual coverage altogether.