Why does fedora-minimal ship gcc, all of Perl, and unzip? Pulling one thread removed 281 packages

I keep archive extractors out of my offline templates on purpose — unzip and friends are exactly the kind of parser attack surface a vault qube should never carry. So I was surprised to find this in a template that never had it installed:

$ rpm -q unzip
unzip-6.0-69.fc44.x86_64

Traced it back to fedora-44-minimal itself. The chain:

perl-devel → redhat-rpm-config → zip → unzip

and that same chain is quietly holding a full build toolchain in “minimal”: gcc, gcc-c++, binutils, make, glibc-devel, kernel-headers, plus the entire Perl distribution (~270 modules, including perl-Archive-Zip and perl-Archive-Tar — more archive parsers).

The kicker — on a virgin minimal clone:

$ sudo dnf remove zip

Transaction Summary: Removing: 281 packages (326 MiB freed)

I’ve done it in a test clone: desktop stack fine, reboots fine, dnf update quiet. Only real casualty is file (rides out as an unused dep — I re-added it).

Three questions:

  • Is this intended? Does anything in the Qubes template build actually need rpm-build machinery and gcc at runtime, or is this a packaging accident inherited from Fedora?

  • Is dnf remove zip the sane fix, or is there a better way to trim it?

  • Anyone know what breaks? Nothing I run has missed it yet, but I’d like to hear the corner case before rebuilding my whole lineage on the trimmed trunk.

Check your own minimal-derived templates:

rpm -q zip unzip gcc perl redhat-rpm-config

(Qubes 4.3.1, qubes-template-fedora-44-minimal.)

If you want some specific answer here, you need to provide more context about your researchs. Otherwise, you will end up with a disappointing answer like this:

That’s fair. Context: my concern is that minimal-template bloat ends up in my vault qube’s lineage, and some of it (unzip, perl-Archive-Zip/Tar) is parser attack surface a vault should never carry.

Tracing where it comes from — the template’s own build history survives in dnf history. Transaction 2 of fedora-44-minimal:

dnf install -y […] qubes-vm-dependencies      # 695 packages; no install_weak_deps=False

Then dnf repoquery --installed --whatrequires at each link: nothing requires perl except perl-CPAN (Perl itself), and nothing requires qubes-vm-dependencies — but perl-devel → redhat-rpm-config → zip → unzip hard-chain the toolchain (gcc, binutils, make, glibc-devel, kernel-headers, ~270 perl modules) to each other.

So it looks like weak-dep fallout of the build meta, orphaned ever since. On a near-virgin minimal clone, sudo dnf remove zip proposes 281 packages / 326 MiB — none of it qubes-* — and post-removal the agents, desktop stack, reboot, and updates are all fine so far.

Unless someone knows a reason this chain must ship, my read is that it’s a build-time accident — and I’ll file it against qubes-builder this week (suggested fix: install_weak_deps=False when installing qubes-vm-dependencies; full transaction logs and the removal test attached). If that chain is load-bearing somewhere I haven’t looked, please shout.

Meanwhile, anyone can check their own minimal-derived templates: rpm -q zip unzip gcc perl — I’d be curious whether 4.2-era templates show the same.

same in r4.2 fedora minimal template:

zip-3.0-44.fc43.x86_64
unzip-6.0-67.fc43.x86_64
gcc-15.2.1-7.fc43.x86_64
perl-5.42.2-523.fc43.x86_64

Notable that debian minimal template only included perl from this list (apt list –installed zip unzip gcc perl), which is a removable package according to @qubist’s minifying debian guide.