Where Everything Inside Linux Packages Live

Every chapter in this section has referenced individual locations as they came up — the package database, repository config, cache directories. This chapter pulls all of it together into one comprehensive reference, side by side across both distro families, answering completely: where does a package actually put things?

The Package Database Itself

This is the authoritative record from the very first chapter of this section — every installed package and every file it owns.

ls /var/lib/dpkg/
ls /var/lib/rpm/

Never edit anything under these directories by hand — every interaction with the package database should go through dpkg/rpm or their higher-level wrappers.

Downloaded Package Cache

Both high-level tools cache downloaded package files locally, so a repeated install (or a rollback) doesn’t necessarily need to re-download anything already fetched once.

du -sh /var/cache/apt/archives/
du -sh /var/cache/dnf/

This cache can genuinely grow large over time on a system that installs and upgrades software frequently — apt clean and dnf clean all, covered in their respective chapters, are exactly how you reclaim that space.

Repository Configuration

Installed Binaries

This follows the Filesystem Hierarchy Standard conventions established earlier in this course, identically across both families:

That last row matters specifically for this section: anything you make install yourself, or place manually, belongs in /usr/local, never directly in /usr/bin — keeping package-managed and manually-managed software cleanly separated, exactly the distinction drawn back when /usr vs. /usr/local was first introduced.

Configuration Files

Both hello-tool examples built earlier in this section deliberately skipped shipping any configuration file, to keep the walkthroughs focused — but a real package with configuration would place it here, and it’s exactly these files that Debian’s remove/purge distinction, and RPM’s .rpmsave/.rpmnew mechanism, are built around protecting.

Documentation

ls /usr/share/doc/bash/
man bash

Shared Libraries

systemd Units Shipped By A Package

Directly connecting back to the Services & Boot section of this course: a package that installs a background service typically ships its own unit file.

Runtime State And Variable Data

Putting It All Together: Tracing One Real Package

Rather than trusting the table alone, confirm it directly — pick any installed package and see every category represented:

dpkg -L nginx | sort

/etc/nginx
/etc/nginx/nginx.conf
/lib/systemd/system/nginx.service
/usr/sbin/nginx
/usr/share/doc/nginx
/usr/share/man/man8/nginx.8.gz
/var/log/nginx

Every single row from the tables above, represented in one real package’s file list — configuration under /etc, the binary under /usr/sbin, a systemd unit under /lib/systemd/system, documentation under /usr/share, and a dedicated log directory under /var/log. The RPM equivalent, rpm -ql nginx, would show the same categorical spread, just with dnf/rpm-specific paths for the database and cache pieces that sit outside what any individual package’s file list would ever show.

A Consolidated Reference Table

Notice how much of the right-hand structure is genuinely identical between the two families — the real divergence is almost entirely in package-manager-specific territory (the database and cache locations, and repository configuration), while everything a package actually installs follows the same shared Filesystem Hierarchy Standard conventions either way.

What’s Next

With every location mapped, the next chapter puts this map to direct use — the real answer to “how do I get a system completely back to zero” after removing something, including the files a package manager’s own removal command won’t touch on its own.