Updating One Repo in APT without Deleting Configuration Files

Update a specific repository in APT by temporarily modifying its priority in /etc/apt/preferences.d/ or using the -t flag with apt-get. This approach targets packages from a designated source without triggering full system upgrades, ensuring that existing configuration files remain intact and preventing unintended side effects during Docker image builds.

Understanding APT Repository Priorities

The Advanced Package Tool (APT) manages software installation on Debian-based systems like Ubuntu and Kali Linux. By default, APT checks all enabled repositories for updates. When you run apt-get update, it refreshes the package lists from every configured source. However, running apt-get upgrade afterward will attempt to upgrade all installed packages to their newest versions across all repositories. This broad scope is often undesirable in containerized environments where stability and reproducibility are critical. You might only want to pull new versions from a specific third-party repository, such as one providing proprietary drivers or experimental software, while leaving the core system packages untouched. To achieve this isolation, you must understand how APT determines which version of a package to install. APT uses a combination of repository priorities and pinning mechanisms. Without explicit instructions, APT selects the highest version number available across all sources. If a specific repository contains newer packages than the main distribution, those packages will be selected for upgrade unless restricted. Therefore, updating a single repo requires either restricting the upgrade command to only those packages or temporarily altering the priority of other repositories.

The Role of Configuration Files

When upgrading packages, APT carefully handles configuration files. If a package has been modified locally, APT typically prompts the user to choose between the maintainer's version and the local version. In automated scripts or Docker builds, these prompts can cause failures or unexpected behavior. The goal is to ensure that even when updating specific packages, the configuration files associated with them are not overwritten unless explicitly intended. This preservation is vital for maintaining the state of services within a container or server instance.

Method 1: Using Target Release Flags

The most direct way to update packages from a specific repository is to use the target release flag. This method tells APT to only consider packages that belong to a specific distribution or suite. For example, if you have added a repository for "testing" but primarily want to stay on "stable," you can restrict your upgrade operation. Use the following command to update only packages from a specific release:

apt-get update
apt-get -t testing upgrade

In this scenario, -t testing instructs APT to look for upgrades only among packages labeled as part of the "testing" suite. Packages from the "stable" repository will be ignored, even if newer versions are available there. This ensures that your core system configuration remains stable while allowing you to fetch updates from the targeted source. It is important to note that this command will upgrade all packages that match the specified target, not just a single package. If you need to update a single package from that repo, replace upgrade with the package name:

apt-get -t testing install package-name

This approach is safe because it does not modify any configuration files permanently. It simply filters the list of candidates for the current transaction. Once the command finishes, the system returns to its previous state regarding repository priorities.

Method 2: Pinning Repository Priority

For more granular control, especially in complex environments like Dockerfiles, you can set permanent or temporary priority levels for repositories. This is done using the /etc/apt/preferences.d/ directory. By creating a file here, you can assign a numeric priority to a specific repository. APT uses these numbers to decide which version to prefer when multiple versions are available. Create a file named specific-repo.pref in /etc/apt/preferences.d/:

Package: *
Pin: release o=SpecificRepo
Pin-Priority: 900

Replace SpecificRepo with the origin identifier of your target repository. A priority of 900 ensures that packages from this repo are preferred over those from standard repositories, which typically have lower priorities. To revert this change, simply delete the preference file. This method is particularly useful when you frequently interact with a non-standard repository and want to avoid typing flags repeatedly. However, it requires careful management to prevent accidental upgrades of unrelated packages.

Docker-Specific Considerations

In Docker images, the filesystem is ephemeral. Any changes made to /etc/apt/preferences.d/ must be applied within the same RUN instruction or saved via a custom base image. Combining the update and install steps into a single layer helps reduce image size and complexity.

RUN apt-get update && \
    apt-get -t my-custom-repo install --no-install-recommends -y package-name && \
    rm -rf /var/lib/apt/lists/*

This pattern ensures that the repository metadata is refreshed, the specific package is installed from the desired source, and temporary files are cleaned up. It avoids leaving behind configuration changes that could interfere with subsequent build steps. For more information on managing package errors during this process, see Fixing E: Sub-process /usr/bin/dpkg returned an error code (1) on Kali Linux. Additionally, if you encounter issues with missing packages in your list, check Remove package from apt update list for troubleshooting tips.

Verifying the Update

After performing the update, verify that only the intended packages were changed. Use apt-get upgrade --dry-run to simulate the action without making changes. This allows you to review the list of packages that would be upgraded. If the output includes packages from repositories you did not intend to touch, adjust your flags or pinning settings accordingly. Always test these commands in a non-production environment first to ensure they behave as expected.

Frequently Asked Questions

Will this method delete my existing configuration files?

No, APT preserves existing configuration files by default unless you force an overwrite. When upgrading, it asks whether to keep the local version or install the new one. In automated modes, it usually keeps the local version to prevent service disruption.

Can I update a package from a repo without adding it to sources.list?

You cannot directly install from a URL without adding it to the sources list or using a local .deb file. However, once added, you can use the -t flag to isolate updates from that specific repository.

What happens if I pin a repository too high?

If you pin a repository with a very high priority, APT may downgrade packages from other sources to match the pinned repo's versions. This can lead to instability. Stick to priorities below 1000 unless you fully understand the implications.

How do I remove a pinned repository after use?

Simply delete the preference file created in /etc/apt/preferences.d/. Then, run apt-get update to reset the priority cache. This restores the default behavior of APT.

Is it safe to use dry-run before actual upgrades?

Yes, --dry-run is highly recommended. It shows exactly what changes would occur without modifying the system. This is crucial for verifying that only the intended packages are affected by your update strategy.