Concepts·LPIC-1

LPIC-1 lab: Debian and RPM package families

Objectives 102.4 and 102.5 examine Debian and RPM package management separately, and both appear on the 101 paper. This guide asks each family the same three ordinary questions - what tools do you have, which package owns this file, what does that package contain - and is specific about where the two answers differ in shape, in wording and in the package name itself.

Start Here Guide 2 of 33 Beginner

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
TimeAbout 15 min

RPM packagingrpm 4.19.1.1, dnf 4.20.0

Both package families, because LPI names dpkg and rpm in the objectives themselves. Every output is captured on the host it belongs to.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC1-A01	192.168.0.76	Ubuntu 26.04 LTS	Debian-family host - dpkg and apt, which objective 102.4 names	2 Core	4 GB	50 GB
LPIC1-B01	192.168.0.77	AlmaLinux 10.2	RPM-family host - rpm and dnf, which objective 102.5 names	2 Core	4 GB	50 GB

This guide includes

Use this before the packaging objectives. This matters because 102.4 and 102.5 examine Debian and RPM separately - the same question has two answers, and both are examinable.

learning which tools each objective names
asking which package owns a file, on each family
listing what that package contains, both ways

Before you start

what-lpic-1-asks

The tools each objective names
102.4 names one pair, 102.5 names the other. Both pairs are examined.
bash Example session
```
$dpkg --version | head -1; apt --version; echo "--- objective 102.4 names these"Debian 'dpkg' package management program version 1.23.7 (amd64).apt 3.2.0 (amd64)--- objective 102.4 names these$rpm --version; dnf --version | head -1; echo "--- objective 102.5 names these"RPM version 4.19.1.14.20.0--- objective 102.5 names these
```
Note
Low-level and high-level are examined separately, and confusing them is the commonest way to lose a mark here. dpkg and rpm operate on one package file at a time and do NOT resolve dependencies - hand dpkg -i a package whose dependency is missing and it refuses, telling you exactly what it wanted. apt and dnf sit above them, talk to repositories, work out the dependency graph and then call the low-level tool.

Which is why dpkg -i failing is not a bug. It is the tool doing its job. The fix is apt-get install -f, which asks the high-level tool to repair what the low-level one could not.

dnf 4, not dnf5. AlmaLinux 10.2 ships dnf 4.20.0. The dnf5 rewrite changes some output formatting and a few flag spellings; nothing on this path depends on it, but it is worth knowing before you compare your terminal against this page.

apt against apt-get. apt is the friendlier front end with a progress bar and colour; apt-get has a stable, scriptable interface. Use apt at a prompt and apt-get in a script - apt itself warns you about exactly that.

Expected resultdpkg 1.23.7 with apt 3.2.0, and rpm 4.19.1.1 with dnf 4.20.0.

Success conditionYou have both toolchains in front of you and know which layer each sits in.
The same question, asked twice
Which package owns a file - on each family.
bash Example session
```
$dpkg -S /usr/bin/sshopenssh-client: /usr/bin/ssh$rpm -qf /usr/bin/sshopenssh-clients-9.9p1-23.el10_2.alma.1.x86_64
```
Note
The package is not even called the same thing. openssh-client on Debian, openssh-clients on RPM - singular against plural, for the same software. Package names differ across families far more often than people expect, and a question that hinges on one is asking whether you have actually used both.

And the answers have different shapes. dpkg -S prints package: path. rpm -qf prints the full name-version-release-architecture, which is a great deal more information and is a nuisance when you only wanted the name - rpm -qf --queryformat '%{NAME}\\n' fixes that.

These search the INSTALLED database, not the filesystem. A file that no package owns - something you compiled, or a stray copy - produces "no path found matching pattern" rather than a package name, and that is a genuinely useful answer when auditing a machine.

dpkg -S takes a pattern, and that surprises people. dpkg -S ssh matches every path containing the string, across many packages. Give it a full path when you want one answer.

Expected resultopenssh-client: /usr/bin/ssh on Debian, and the full NEVRA openssh-clients-9.9p1-23.el10_2.alma.1.x86_64 on RPM.

Success conditionYou can answer an ownership question on either family.
What that package contains
The listing question, both ways - and they do not line up.
bash Example session
```
$echo "what does that package contain?"; dpkg -L openssh-client | head -6what does that package contain?/./etc/etc/ssh/etc/ssh/ssh_config/etc/ssh/ssh_config.d/usr$echo "what does that package contain?"; rpm -ql openssh-clients | head -6what does that package contain?/etc/ssh/ssh_config/etc/ssh/ssh_config.d/etc/ssh/ssh_config.d/50-redhat.conf/usr/bin/scp/usr/bin/sftp/usr/bin/ssh
```
Note
dpkg -L includes directories, rpm -ql does not. That is why the two listings do not correspond even for the same software - the Debian one opens with /., /etc, /etc/ssh before reaching a file. Piping either through grep bin/ is the usual way to see only the programs, and is worth making a habit.

Remember the letters, because there is no pattern to help you. dpkg -S searches for the owner of a file; dpkg -L lists a package's files. rpm spells the same two -qf and -ql. Both pairs are examined and the mnemonic people invent for one does not transfer to the other.

Both read the installed database, so both need the package installed. To ask the same question of a file you have downloaded but not installed, Debian wants dpkg -c (contents of an archive) and RPM wants rpm -qlp - the p meaning "the package file, not the installed one". Forgetting the p is a classic exam trap.

rpm -qc and dpkg-query -W -f='${Conffiles}' narrow the list to configuration, which is usually the part you actually wanted.

Expected resultdpkg -L starts at /. and lists directories as well as files; rpm -ql lists paths only, beginning at /etc/ssh/ssh_config.

Success conditionYou can list a package's contents on either family and read the difference.

Troubleshooting

dpkg -S /path/to/file reports no package owns a file that plainly exists.

Why: The file was not installed by a package - it was created by a script, an installer or by hand - or the path given is a symlink to the real location.

Fix:Resolve the path first with readlink -f, then query again. On the RPM family the equivalent is rpm -qf <path>, which answers with the full NEVRA.
You need the package for a command that is not installed yet, and dpkg -S cannot find it.

Why: dpkg only knows about installed packages. The RPM family's dnf provides searches the repository metadata instead.

Fix:On the RPM family use dnf provides */<command>. On Debian install apt-file, run apt-file update once, then apt-file search bin/<command> - it is not available by default.
dpkg -L <package> output looks like it contains directories that belong to other packages.

Why: The listing starts at / and includes every directory on the path to each file, not only the files the package uniquely owns.

Fix:Filter to real files with dpkg -L <pkg> | xargs -I{} sh -c 'test -f {} && echo {}', or use rpm -ql on the RPM family, which behaves the same way.

Official sources

← All LPIC-1 guides

LPIC-1 lab: Debian and RPM package families

This guide includes

Before you start

The tools each objective names

The same question, asked twice

What that package contains

Troubleshooting

Official sources