15.3 Metapackages and Custom Repositories

Kali packages 600+ tools, but a default install ships only a subset of them and no two engagements need the same set. A wireless team wants kali-tools-wireless; a stripped-down cloud box wants far less than the full desktop. Kali solves this with metapackages, and the exam expects you to know what they are, the names of the major ones, and how to build and host your own.

What a Metapackage Is

A metapackage is a package that contains (almost) no files of its own. Its entire payload is the Depends: line in its control metadata: installing it forces APT to install everything it depends on, and removing it lets apt autoremove clean the whole set back out. Inspect one yourself:

apt-cache depends kali-linux-default
apt-cache show kali-linux-default | grep -E '^(Package|Depends)'

You will see a long dependency list and no meaningful file list. This is pure package-management leverage: one name stands in for a curated toolset.

The kali-linux-* and kali-tools-* Families

Two exam angles here. First, know the ordering: core ⊂ headless ⊂ default ⊂ large ⊂ everything. Second, know the practical use: a minimal install (kali-linux-core) plus exactly the category sets you need is the standard recipe for slim, purpose-built Kali machines, and installing kali-linux-large is the one-command answer to "my ISO is missing tools."

Building Your Own Metapackage with equivs

Your organization will want its own set — say, the corporate toolset plus internal scripts. The equivs package exists precisely for building dependency-only packages without learning full Debian packaging:

apt install -y equivs
equivs-control acme-kali-tools

This writes a template control file. Edit it:

Section: misc
Priority: optional
Standards-Version: 4.5.0
Package: acme-kali-tools
Version: 1.0
Maintainer: SecOps <secops@example.com>
Depends: kali-linux-default, kali-tools-web, openssh-server
Description: Acme Corp standard Kali toolset
 Metapackage pulling in the approved toolset for engagement machines.

Build and install:

equivs-build acme-kali-tools          # produces acme-kali-tools_1.0_all.deb
apt install ./acme-kali-tools_1.0_all.deb

Because it is a real package, it shows up in dpkg -l, upgrades cleanly when you bump Version:, and its dependencies are enforced by APT. The lower-level alternative is dpkg-deb --build against a directory tree containing a hand-written DEBIAN/control file — same result, more manual steps. Know that both exist. Note that Kali Linux Revealed itself does not use equivs: its worked example builds a package the full Debian way, creating the payload directory, running dh_make --native (package type indep), editing debian/control, listing what goes where in debian/<package>.install, and building with dpkg-buildpackage -us -uc.

Hosting a Custom Repository with reprepro

Copying .deb files around with dpkg -i scales as badly as SSH loops do. The professional move is an internal APT repository: one server holds your packages, and every Kali box installs them with plain apt. The book's tool for this is reprepro, which manages a repository as a plain directory tree you can serve with any web server.

apt install -y reprepro apache2
mkdir -p /srv/repo/conf

Create /srv/repo/conf/distributions:

Origin: Acme Corp
Label: acme-internal
Codename: kali-rolling
Architectures: amd64 all
Components: main
Description: Acme internal Kali packages
SignWith: ABCD1234

Codename anchors the suite your clients will request (matching kali-rolling keeps things simple); Architectures and Components define the repo layout; SignWith names the GPG key reprepro uses to sign the Release file, because clients will (and should) verify signatures just as they do against Kali's own GPG-signed repositories.

Add packages and publish:

reprepro -b /srv/repo includedeb kali-rolling acme-kali-tools_1.0_all.deb
reprepro -b /srv/repo list kali-rolling

reprepro copies the .deb into a pool, regenerates the Packages index, and re-signs Release. Point Apache at /srv/repo (excluding conf/ and db/) and clients consume it with a line in /etc/apt/sources.list.d/acme.list:

deb http://repo.acme.internal/ kali-rolling main

plus your public key in their keyring (modern style: a signed-by= option pointing at a keyring file). One apt update && apt install acme-kali-tools on any machine now deploys your entire standard toolset.

The Incoming Queue

For teams, reprepro supports an incoming queue: a drop directory where CI systems or developers upload packages, processed automatically according to conf/incoming:

Name: default
IncomingDir: incoming
TempDir: tmp
Allow: kali-rolling

reprepro -b /srv/repo processincoming default validates each upload (checksums, signatures if required) and files it into the named distribution — no one needs shell access to the repository layout itself.

APT Pinning: Preferring Your Repository

One last operational detail: when your internal repo carries a forked package that also exists in Kali's repositories, APT normally picks the highest version number. To guarantee your repository wins (or to keep your metapackages from being shadowed), use APT pinning in /etc/apt/preferences.d/acme:

Package: *
Pin: origin repo.acme.internal
Pin-Priority: 900

The default priority is 500, so 900 makes your origin authoritative; verify the result with apt-cache policy somepackage, which shows the candidate version and every pin that influenced the choice. Pinning plus the kali1 version suffix gives you two independent levers — version ordering and priority — for controlling exactly which build of a package your fleet runs.

Putting It Together

The pattern to remember for the exam: metapackage defines the toolset, reprepro distributes it, APT enforces it. Version 1.1 of acme-kali-tools that adds a new tool becomes a fleet-wide upgrade via a routine apt upgrade — the same mechanism Kali itself uses to evolve the kali-linux-default set on the rolling release.