Describe what is physically inside a .deb file and inside an .rpm file: where does each format keep its metadata, its file payload, and its maintainer scripts?

## Why the anatomy matters Both formats have to answer the same questions before anything is written to disk: what is this package called, what version is it, what does it need, what will it install, and what code must run around the install. How each format stores those answers explains several behaviours that otherwise look arbitrary. ## The .deb container A Debian binary package is an `ar` archive — the ancient Unix archive format also used for static libraries — with exactly three members, in order: 1. **`debian-binary`** — a tiny text file containing the format version, currently `2.0`. Its presence first lets a tool identify the file cheaply. 2. **`control.tar.*`** — the metadata archive (gzip, xz or zstd compressed). 3. **`data.tar.*`** — the payload archive. Inside the control archive: - **`control`** — an RFC822-style stanza with `Package`, `Version`, `Architecture`, `Maintainer`, `Description`, and the relationship fields (`Depends`, `Pre-Depends`, `Recommends`, `Suggests`, `Conflicts`, `Breaks`, `Replaces`, `Provides`). This is the stanza that gets copied into the repository's index file, which is how a resolver can plan without downloading anything. - **`md5sums`** — digests of the shipped files, used to detect local modification. - **`conffiles`** — the list of paths that are configuration and must therefore be *preserved* rather than overwritten when the package is upgraded. - **maintainer scripts** — `preinst`, `postinst`, `prerm`, `postrm`, and optionally `triggers`. These are ordinary executables (usually shell) run by the installer, as root, at defined points around unpacking and removal. The data archive holds the payload as a normal tar tree rooted at `/`: `./usr/bin/myapp`, `./etc/myapp/config`, and so on, with ownership and modes recorded in the tar headers. ## The .rpm container An RPM file is a single binary structure, not a nest of archives: 1. **Lead** — a fixed 96-byte legacy structure, retained for file-type identification only; modern tools do not rely on it. 2. **Signature header** — digests and the GPG signature over the rest of the file, which is why an individual RPM is independently verifiable. 3. **Header** — the real metadata: a tag/value store keyed by numeric tags. It carries name, version, release, epoch, architecture, the `Requires`/`Provides`/`Conflicts`/`Obsoletes` relationships, the complete file list with paths, sizes, modes, users, groups and per-file digests, and the **scriptlets** (`%pre`, `%post`, `%preun`, `%postun`, plus transaction-scoped `%pretrans`/`%posttrans` and trigger scriptlets) stored as header tags with an associated interpreter. 4. **Payload** — a `cpio` archive, compressed with gzip, xz or zstd depending on the distribution's build settings. A consequence worth naming in an interview: because the file list is *in the header*, RPM can tell you every path a package will install, with its mode and digest, without touching the payload — and it can later verify an installed system against those recorded digests. ## Relationship declarations, not bundled dependencies Neither format embeds the packages it depends on. Both declare names and version ranges and leave satisfaction to the resolver. RPM additionally auto-generates fine-grained dependencies at build time: shared-library sonames like `libc.so.6(GLIBC_2.34)(64bit)`, plus interpreter-level requirements. Debian's equivalent granularity comes from `shlibs`/`symbols` files that turn a linked library into a versioned `Depends` on the package that provides it. ## Maintainer scripts are privileged code On both sides the scripts run as root, before and after the files move. They are why installing a package is a trust decision and not merely a file copy: a package can create system users, generate keys, migrate a database schema, or do anything else root can do. The ordering during an *upgrade* is the part candidates get wrong — the new package's pre-install script runs, files are replaced, then the old package's removal script runs with an argument telling it that it is being upgraded rather than purged, and finally the new post-install script runs. A removal script that does not check that argument can happily undo the upgrade it is part of. ## Configuration files get special treatment Because a `conffile` (Debian) or a file marked `%config(noreplace)` (RPM) may have been edited by the administrator, upgrades do not simply overwrite it. Debian's installer compares digests and, if the file was modified, prompts or leaves the new version beside it as `.dpkg-dist`, keeping your version. RPM either installs the new file and saves yours as `.rpmsave`, or keeps yours and drops the new one as `.rpmnew`, depending on the flag used. Finding stray `.rpmnew` files on an old server is a classic sign that upgrades have been applied without anyone reconciling configuration. ## Source packages Both ecosystems also have a source form. A Debian source package is a set of files — a `.dsc` control file, an upstream tarball, and a Debian-specific tarball of packaging — while RPM ships a single `.src.rpm` containing the spec file and its sources. Building either produces the binary packages; distributions build in clean isolated chroots so the result depends only on declared build dependencies.