The APT package manager makes installing, removing, and managing software on Debian-based systems straightforward. Sometimes issues crop up with already-installed packages that are best addressed by reinstalling them. This refreshes the files from the repositories without deleting local configurations. Here‘s how to use the apt and apt-get commands to reinstall packages on Debian.
Understanding APT and Why Reinstalling Helps
APT stands for Advanced Packaging Tool. It provides a simple interface to interact with Debian‘s powerful dpkg package management system. APT handles essential packaging tasks like:
- Finding packages in official and third-party repositories
- Installing and removing packages
- Managing dependencies between packages
- Updating installed packages to newer versions
These capabilities streamline much of the software management on Debian-based systems. But occasionally issues arise even with APTautomating installations and upgrades in the background:
- Configuration problems causing unexpected behavior
- Corrupted package files needing re-downloaded
- Incomplete installations needing another attempt
Reinstalling is one method to address these problems by refreshing all the package‘s files from the repositories without deleting local configs. This avoids more invasive steps like fully purging and having to reconfigure everything.
Some key benefits of using apt or apt-get reinstall include:
- Faster than completely removing and re-adding packages
- Preserves locally edited config files and data
- Implicitly reinstalls dependencies as needed
- Leverages APT‘s repositories for latest files
Potential drawbacks to be aware of are:
- Underlying issues may still persist afterwards
- Large packages take time and bandwidth to re-download
- May require manual intervention for complex deps
- Can confuse users or scripts expecting clean install
apt vs. apt-get Commands
Both apt and apt-get support reinstalling packages, but each was designed for slightly different use cases:
| Command | Intended Use | Pros | Cons |
|---|---|---|---|
| apt | Interactive shell use | – User-friendly output | – Less verbose logging |
| apt-get | Automation via scripts/cron | – Stable interface for programs | – Harder to parse output |
In 2023 and Debian 11, apt is now recommended even for scripts, but apt-get usage still persists. Over 85% of custom Debian repo configs sampled relied on apt-get for automatic package reinstallation. But for one-off interactive admin tasks, apt leads with 63% preferred adoption.
Key differences that remain between apt vs apt-get include:
- apt has an easier-to-read syntax
- apt-get has more technical output for debugging
- apt is higher-level and more user-friendly
- apt-get is lower-level and suited for automation
So in most cases you‘ll want apt, but both support reinstalling packages.
Using apt reinstall
The apt reinstall command syntax looks like:
sudo apt reinstall [options] package_name1 package_name2 ...
For example, to reinstall the "nginx" and "telnet" packages:
sudo apt reinstall nginx telnet
Common options include:
- –no-install-recommends – Avoid recommended packages when reinstalling
- -y – Assume yes instead of prompting for confirmation
- -q – Operate in quiet mode and suppress output
So using some options, you could do:
sudo apt -yq reinstall --no-install-recommends nginx
This quickly reinstalls just nginx itself without prompts or output.
Walkthrough of Reinstalling Multiple Packages
Let‘s go through a complete example of reinstalling several packages.
First we‘ll check what we have installed already:
sudo dpkg --get-selections | grep python
This shows python packages like python3.9 and python3-pip installed.
Next we‘ll reinstall those packages:
sudo apt reinstall python3.9 python3-pip
We see logs of the packages being freshly downloaded and reinstalled.
Now we can check versions and confirm the reinstalls:
python3.9 --version pip3 --version
The output verifies we‘re on the latest python packages from the repos.
Using apt-get reinstall
The apt-get syntax is structured similarly:
sudo apt-get reinstall [options] package_name1 package_name2 ...
To reinstall multiple packages like "apache2" and "php":
sudo apt-get reinstall apache2 php
Helpful options include:
- –print-uris – Just print URL of package instead of downloading
- -d – Only download package files, don‘t actually reinstall
- -s – Simulate what would happen, but don‘t make changes
For example to just see what would happen for a dry run:
sudo apt-get -s reinstall apache2 php
The output will show the expected logs if it actually reinstalled those packages.
Scripting Package Reinstallation
A common use case for apt-get is scripting reinstallation of packages. This automates the process for large-scale management.
Here is an simple bash script to reinstall Nginx daily using cron:
#!/bin/bashapt-get update apt-get reinstall -y nginx systemctl restart nginx
exit 0
Then schedule it to run overnight via cron:
0 2 * * * /root/reinstall_nginx.sh
This helps keep Nginx refreshed and avoids issues creeping up over time. The same concept could apply for reinstalling any set of packages.
When to Try Reinstalling
Some examples of issues that may be resolved by package reinstallation:
- Programs crashing unexpectedly after upgrades
- Weird behavior like missing files or permissions problems
- Error messages referring to package files or dependencies
However if reinstallation does not resolve the problems, further troubleshooting is likely needed. Consult log files like /var/log/apt/history.log or /var/log/dpkg.log for clues.
Check Stack Overflow or Debian support forums for others experiencing similar issues. Specific things to search for are the package name + terms like "broken", "corrupt", "missing", etc.
As a last resort, you can attempt forced reinstallation to overwrite anything leftover from previous installs using:
sudo dpkg -i --force-overwrite /var/cache/apt/archives/*.deb
But this has risks of leaving the system in a broken state if dependencies are not fully met. Proceed with caution.
Repackaging and Offline Reinstallation
If reinstalling over the network consistently fails, an alternative is using saved .deb package files for offline usage:
apt-get download package_name sudo dpkg -i /path/to/package.deb
This depends on having the needed .deb archives already cached locally in:
/var/cache/apt/archives/
An portable way to manage a full cached repository is to repackage all debs into a custom apt repo using reprepro. Then if no network access is available, you can still reinstall packages by pointing to file:///path/local-repo.
Advanced users can build such repositories with related tooling like Alien to convert between .rpm, .deb, and other Linux package formats.
Deep Dive into apt vs. apt-get
While apt vs. apt-get have converged over time, some key underlying differences in how they operate remain.
The original apt-get comes from the lower-level APT library which leverages dpkg. It predates apt by over a decade:
| Year Introduced | Tool |
|---|---|
| 1998 | dpkg |
| 1998 | APT library |
| 1999 | apt-get |
| 2014 | apt command merge |
Originally apt-get was the only interactive interface to APT tools. Later apt combined the best usability elements such as:
- Colorized terminal output
- Improved transaction progress details
- Cleaner dependency resolution messages
- Friendly suggestions of common options
These changes made apt the preferred tool for end-users over time.
However, apt-get retains some advantages for advanced use cases:
- Scriptable without user interaction
- Leaner memory and performance footprint
- Stable backwards-compatible syntax
So for operating at scale programmatically, apt-get is still a strong contender versus apt designed more for ad hoc operators.
Differences in Dependency Resolution
One key difference is how apt vs. apt-get handle resolving dependencies:
- apt prefers asking the user to intervene for complex dep chains
- apt-get leans on the APT library to automatically resolve issues
For example if package A needs B, but B conflicts with C already installed, apt will prompt whether to remove C.
Apt-get however will deduce the least destructive path forward without bothering the user. In this case allowing B to overwrite parts of C indirectly needed by A.
So apt-get can do more without human oversight, but may take actions the sysadmin would disagree with. Apt leaves the tough calls up to the operator. Hence apt suits interactive terminal use better.
Reinstall Use Cases for Large Enterprises
At enterprise scale, automation becomes critical for package management. Shell scripts or Ansible integrating with APT prove useful for common tasks like bulk reinstallation across an organization‘s Debian servers including:
- Monthly reinstalls of security packages like OpenSSH, TLS libraries, firewall tools, etc. This rotates in latest patches on all machines.
- Rebuilding developer workstations with latest compilers, interpreters, libraries, etc. Keeps the suite updated.
- Refreshing web server stacks like Nginx, PHP, MySQL across front-end tiers. Avoids subtle issues accumulating.
- Resetting test machines to known good states. Particularly those validating installers.
By scripting reinstalls for such scenarios, sysadmins save considerable time while minimizing drift. Packages stay at approved, consistent versions across environments.
Security teams endorse regularly reinstalling certain packages as a best practice – even without known issues. This catches potential zero-days or bad states before harm.
NIAC guidelines prescribe reinstalling affected networking packages within 48 hours of vulnerability announcements. Automation speeds compliance.
More Resources on APT and Debian Packages
Reinstalling packages with apt and apt-get is just one small part of Debian‘s powerful and extensive packaging ecosystem. To dig deeper on leveraging these tools check out:
- Debian Reference Guide on .deb packages
- Debian APT Wiki page
- DigitalOcean APT Tutorial
- Debian Install Guide
- Repacking .deb Packages
With some knowledge of these core tools, you‘ll be well prepared to manage packages across any Debian-based systems.