Posted on by patrick

Beyond the basics of Linux software installations: Become an expert in the configuration of apt-get in 2025

apt-get is used to install software on various Linux systems, including Ubuntu, Debian, Pop!_os, et. al. Sometimes, you’ll experience errors installing software using apt-get. In this post, I will cover what I’ve learned about how apt-get configuration works.

Let’s start with a discussion about how the apt-get binary knows where to find packages on the Internet.

The Primary Source: /etc/apt/sources.list

The /etc/apt/sources.list file is the central configuration file that tells apt-get where to look for packages. Each line in this file represents a repository – a server containing packages that can be installed on your system.
A typical entry in sources.list looks like this:

deb http://deb.debian.org/debian bookworm main contrib non-free

This single line contains several key pieces of information:

  • The repository type (deb)
  • The repository URL (http://deb.debian.org/debian)
  • The distribution release name (bookworm)
  • The components to include (main contrib non-free)

The sources.list file can contain multiple repository lines, allowing you to install packages from various sources.

Modular Configuration: /etc/apt/sources.list.d/

As systems became more complex, managing everything in a single sources.list file became unwieldy. The /etc/apt/sources.list.d/ directory helps us handle this complexity with a more modular approach to repository management.

This directory contains individual .list files, each typically dedicated to a specific repository or application. For example, when you add a third-party repository for an application like Visual Studio Code, it might create a file called /etc/apt/sources.list.d/vscode.list.

This approach keeps your system organized and makes it easier to remove repositories when you no longer need them. Simply delete the corresponding file, and the repository is gone – no need to edit the main sources.list file and potentially make mistakes.

Repository Types: deb vs. deb-src

You may have noticed that repository lines start with either deb or deb-src. What’s the difference?

deb: Binary Packages

Lines starting with deb point to repositories containing pre-compiled binary packages. These are the packages most users install – they contain the executable programs, libraries, and other files ready to be used on your system.

When you run apt-get install firefox, apt-get downloads and installs the binary package for Firefox from a deb repository.

deb-src: Source Packages

Lines starting with deb-src point to repositories containing source code packages. These aren’t pre-compiled programs but rather the original source code used to build the binary packages.

Source packages are useful for:

  • Developers who want to examine or modify the code
  • Users who need to compile packages with custom options
  • Those who need to troubleshoot issues by looking at the source code

To download source packages, you use commands like apt-get source firefox instead of apt-get install firefox.

Most typical users don’t need deb-src repositories enabled unless they plan to compile software from source or if they need to compile drivers for hardware like usb-wifi adapters.

Understanding Repository Modifiers

Repository lines can include various modifiers that provide additional options and constraints. Let’s break down some common ones:

Architecture Modifiers: [arch=arm64]

deb [arch=arm64] http://deb.debian.org/debian bookworm main

The arch= modifier specifies that this repository should only be used for a specific architecture. In this example, the repository will only be used when looking for packages for the ARM64 architecture. This is particularly useful for systems like Raspberry Pi or when maintaining multi-architecture systems.

Security Modifiers: [signed-by=/usr/share/keyrings/raspbian-archive-keyring.gpg]

deb [signed-by=/usr/share/keyrings/raspbian-archive-keyring.gpg] http://archive.raspbian.org/raspbian/ bookworm main

The signed-by= modifier specifies which GPG key should be used to verify the packages from this repository. This enhances security by ensuring packages are only installed if they’re signed by a trusted key.

Modern Debian-based systems store repository keys in the /usr/share/keyrings/ directory as separate files rather than in a central keyring, making key management more secure and flexible.

Trust Modifiers: [trusted=yes]

deb [trusted=yes] http://repository.example.com/ stable main

The trusted=yes modifier tells apt to trust this repository even if it doesn’t have valid signatures. This should be used with extreme caution, as it bypasses crucial security checks. Only use this for repositories you absolutely trust, like local repositories on your network. This feature comes in helpful if you’re troubleshooting software installation problems using my firmwarebuildercontainers. Learn more about my firmware image creation process here: https://patrickmccanna.net/overview-of-my-repeatable-iot-build-process-using-ansible-docker/

Distribution and Component Modifiers

After the repository URL, you’ll find several additional modifiers:

deb http://deb.debian.org/debian bookworm main contrib non-free-firmware non-free

Distribution Release Names (bookworm)

The first word after the URL (bookworm in this example) specifies which distribution release to use. Debian uses code names for its releases:

  • bookworm: Debian 12
  • bullseye: Debian 11
  • buster: Debian 10

Ubuntu similarly uses names like jammy (22.04), focal (20.04), etc.

You might also see special release names like:

  • stable: Always points to the current stable Debian release
  • testing: Points to the next Debian release in preparation
  • unstable or sid: The development branch of Debian

Component Categories

The words that follow the release name define which components or sections of the repository to use:

main

deb http://deb.debian.org/debian bookworm main

The main component contains packages that:

  • Are considered part of the distribution
  • Comply with the Debian Free Software Guidelines (DFSG)
  • Don’t depend on packages outside the main section

This is the core of any Debian-based distribution and contains most of the software you’ll need.

contrib

deb http://deb.debian.org/debian bookworm main contrib

The contrib component contains packages that:

  • Comply with the DFSG (free software)
  • Depend on packages that are outside the main section

For example, a free software tool that requires a non-free library would be in contrib.

non-free

deb http://deb.debian.org/debian bookworm main contrib non-free

The non-free component contains packages that:

  • Do not comply with the DFSG
  • Have restrictions on use, modification, or distribution

This includes proprietary drivers, firmware, and software with restrictive licenses.

non-free-firmware

deb http://deb.debian.org/debian bookworm main contrib non-free-firmware

The non-free-firmware component is a newer addition that specifically contains non-free firmware packages required for hardware support. This was separated from the general non-free component to make it easier for users to include just the firmware they need without enabling all non-free software.

Distribution & Component modifiers give you some broad ways of controlling the types of software that can be deployed on your system. I don’t know anyone who is using management of apt-get to prevent the deployment of non-free software on the platform. In practice- I just see this as being an annoying hurdle to go through for enabling the deployment of software you want/need at the time you need it. But it is nice to know there is some granularity of control you can implement for reducing the total set of packages that could be deployed on your system.

Putting It All Together

Let’s analyze a complete example:

deb [arch=arm64 signed-by=/usr/share/keyrings/raspbian-archive-keyring.gpg trusted=yes] http://archive.raspbian.org/raspbian/ bookworm main contrib non-free-firmware non-free

This line tells apt-get:

  1. Use binary packages (deb)
  2. Only for ARM64 architecture (arch=arm64)
  3. Verify packages using the specified key (signed-by=...)
  4. Trust this repository even without valid signatures (trusted=yes) – again, use with caution!
  5. Get packages from the specified URL
  6. For the Debian 12 “Bookworm” release
  7. Include packages from all components (main contrib non-free-firmware non-free)

Best Practices for Managing Repositories

  1. Be selective about third-party repositories: Each repository you add increases the risk of package conflicts or security issues.
  2. Use the modular approach: Place third-party repositories in separate files in /etc/apt/sources.list.d/ rather than editing the main sources.list.
  3. Verify GPG keys: Always verify the GPG keys of repositories you add to ensure you’re getting packages from the intended source.
  4. Only enable what you need: Don’t enable deb-src lines unless you actually need source packages.
  5. Be cautious with non-free components: While sometimes necessary for hardware support, non-free components may have license restrictions or security implications.

Conclusion

Understanding how apt-get repositories work gives you more control over your Debian-based system. Whether you’re troubleshooting package issues, setting up a new system, or just curious about how Linux package management works, knowing the ins and outs of repository configuration is invaluable knowledge.

By properly managing your sources.list and leveraging the flexibility of repository modifiers, you can create a stable, secure, and well-maintained system tailored to your specific needs.