APT_PREFERENCES(5)

💅 NAME 💅

okay bestie, welcome to apt_preferences from the APT manual — APT_PREFERENCES(5) — and it is literally the Preference control file for APT. 💖

💖 DESCRIPTION 💖

The APT preferences file /etc/apt/preferences and the fragment files in the /etc/apt/preferences.d/ folder are your little control panel for which versions of packages will be selected for installation. Slay.

Several versions of a package may be available for installation when the sources.list(5) file contains references to more than one distribution (for example, stable and testing). APT assigns a priority to each version that is available. Subject to dependency constraints, apt-get selects the version with the highest priority for installation. The APT preferences override the priorities that APT assigns to package versions by default, thus giving the user control over which one is selected for installation. 💅

Several instances of the same version of a package may be available when the sources.list(5) file contains references to more than one source. In this case apt-get downloads the instance listed earliest in the sources.list(5) file. The APT preferences do not affect the choice of instance, only the choice of version. iykyk — version vs. instance is a whole thing.

⚠️ Okay, real talk: preferences are a strong power in the hands of a system administrator but they can become also their biggest nightmare if used without care! APT will not question the preferences (no cap), so wrong settings can lead to uninstallable packages or wrong decisions while upgrading packages. Even more problems will arise if multiple distribution releases are mixed without a good understanding of the following paragraphs. Packages included in a specific release aren't tested in (and therefore don't always work as expected in) older or newer releases, or together with other packages from different releases. You have been warned. 💀

Note that the files in the /etc/apt/preferences.d directory need to obey the following naming convention: The files have either no or "pref" as filename extension and only contain alphanumeric, hyphen (-), underscore (_) and period (.) characters. Otherwise APT will print a notice that it has ignored a file, unless that file matches a pattern in the Dir::Ignore-Files-Silently configuration list — in which case it will be silently ignored. So don't name your file my cool prefs (final).bak and act surprised, bestie. 🙈

/etc/apt/preferences is parsed first, followed by the files in /etc/apt/preferences.d in lexicographic order. For example, /etc/apt/preferences.d/00-high-priority.pref, /etc/apt/preferences.d/50-mid-priority and /etc/apt/preferences.d/z-low-priority.pref would be parsed in that order. ✨

✨ APT's Default Priority Assignments ✨

If there is no preferences file or if there is no entry in the file that applies to a particular version then the priority assigned to that version is the priority of the distribution to which that version belongs. It is possible to single out a distribution, "the target release", which receives a higher priority than other distributions do by default. The target release can be set on the apt-get command line or in the APT configuration file /etc/apt/apt.conf. Note that this has precedence over any general priority you set in the /etc/apt/preferences file described later, but not over specifically pinned packages. For example,

apt-get install -t testing some-package

APT::Default-Release "stable";

If the target release has been specified then APT uses the following algorithm to set the priorities of the versions of a package. Assign:

• priority 1 — to the versions coming from archives which in their Release files are marked as "NotAutomatic: yes" but not as "ButAutomaticUpgrades: yes" like the Debian experimental archive, as well as versions that are not phased on this systems.
• priority 100 — to the version that is already installed (if any) and to the versions coming from archives which in their Release files are marked as "NotAutomatic: yes" and "ButAutomaticUpgrades: yes" like the Debian backports archive since squeeze-backports.
• priority 500 — to the versions that do not belong to the target release.
• priority 990 — to the versions that belong to the target release.

The highest of those priorities whose description matches the version is assigned to the version.

If the target release has not been specified then APT simply assigns priority 100 to all installed package versions and priority 500 to all uninstalled package versions, except versions coming from archives which in their Release files are marked as "NotAutomatic: yes" — these versions get the priority 1 or priority 100 if it is additionally marked as "ButAutomaticUpgrades: yes".

APT then applies the following rules, listed in order of precedence, to determine which version of a package to install.

• Never downgrade unless the priority of an available version is at least 1000. ("Downgrading" is installing a less recent version of a package in place of a more recent version. Note that all of APT's default priorities are less than 1000; higher priorities can only be set in the preferences file. Note also that downgrading a package can be risky.) 🫣
• Install the highest priority version.
• If two or more versions have the same priority, install the most recent one (that is, the one with the higher version number).
• If two or more versions have the same priority and version number but either the packages differ in some of their metadata or the --reinstall option is given, install the uninstalled one.

In a typical situation, the installed version of a package (priority 100) is not as recent as one of the versions available from the sources listed in the sources.list(5) file (priority 500 or 990). Then the package will be upgraded when apt-get install some-package or apt-get upgrade is executed. 💅

More rarely, the installed version of a package is more recent than any of the other available versions. The package will not be downgraded when apt-get install some-package or apt-get upgrade is executed.

Sometimes the installed version of a package is more recent than the version belonging to the target release, but not as recent as a version belonging to some other distribution. Such a package will indeed be upgraded when apt-get install some-package or apt-get upgrade is executed, because at least one of the available versions has a higher priority than the installed version.

🦋 Phased Updates 🦋

APT understands a field called Phased-Update-Percentage which can be used to control the rollout of a new version. It is an integer between 0 and 100.

A system's eligibility to a phased update is determined by seeding random number generator with the package source name, the version number, and /etc/machine-id, and then calculating an integer in the range [0, 100]. If this integer is larger than the Phased-Update-Percentage, the version is pinned to 1, and thus held back. Otherwise, normal policy rules apply. So yes, your machine is getting a little randomized vibe check. 🎲

In case you have multiple systems that you want to receive the same set of updates, you can set APT::Machine-ID to a UUID such that they all phase the same, or set APT::Get::Never-Include-Phased-Updates or APT::Get::Always-Include-Phased-Updates to true such that APT will never/always consider phased updates.

🌸 The Effect of APT Preferences 🌸

The APT preferences file allows the system administrator to control the assignment of priorities. The file consists of one or more multi-line records separated by blank lines. Records can have one of two forms, a specific form and a general form.

• The specific form assigns a priority (a "Pin-Priority") to one or more specified packages with a specified version or version range. For example, the following record assigns a high priority to all versions of the perl package whose version number begins with "5.32". Multiple packages can be separated by spaces.

Package: perl
Pin: version 5.32*
Pin-Priority: 1001

Since 2.9.9, you can also pin by a source version:

Package: perl
Pin: source-version 5.32*
Pin-Priority: 1001

• The general form assigns a priority to all of the package versions in a given distribution (that is, to all the versions of packages that are listed in a certain Release file) or to all of the package versions coming from a particular Internet site, as identified by the site's fully qualified domain name.

This general-form entry in the APT preferences file applies only to groups of packages. For example, the following record assigns a high priority to all package versions available from the local site.

Package: *
Pin: origin ""
Pin-Priority: 999

A note of caution: the keyword used here is "origin" which can be used to match a hostname. The following record will assign a high priority to all versions available from the server identified by the hostname "ftp.de.debian.org"

Package: *
Pin: origin "ftp.de.debian.org"
Pin-Priority: 999

This should not be confused with the Origin of a distribution as specified in a Release file. What follows the "Origin:" tag in a Release file is not an Internet address but an author or vendor name, such as "Debian" or "Ximian". This is the classic "same word, different vibe" trap. 🙈

The following record assigns a low priority to all package versions belonging to any distribution whose Archive name is "unstable".

Package: *
Pin: release a=unstable
Pin-Priority: 50

The following record assigns a high priority to all package versions belonging to any distribution whose Codename is "forky".

Package: *
Pin: release n=forky
Pin-Priority: 900

The following record assigns a high priority to all package versions belonging to any release whose Archive name is "stable" and whose release Version number is "13".

Package: *
Pin: release a=stable, v=13
Pin-Priority: 500

The effect of the comma operator is similar to an "and" in logic: All conditions must be satisfied for the pin to match. There is one exception: For any type of condition (such as two "a" conditions), only the last such condition is checked.

🎀 Matching packages in the Package field 🎀

The Package field specifies the package that a pinning priority is applied to. The field can either contain a binary package name, a source package name (prefixed with "src:"), a glob(7) expression or a regular expression (surrounded by slashes). Multiple package names, glob(7) expressions and regular expressions can be listed separated by whitespace in which case the record will match any of the matched packages. 💅

By default? Only packages of the native architecture get matched, bestie. That's the default vibe. Wanna match binary packages from any architecture? Just slap the :any suffix onto the package name ✨ And if you're feeling picky and want one specific architecture, append the architecture name to the package name with a colon between them. Easy.

Okay so like, here's an example — it uses a glob expression and a regular expression to hand the priority 500 to every package from experimental where the name starts with gnome (that's the glob(7)-like expression) or contains the word kde (that's a POSIX extended regular expression, wrapped in slashes) 🎀

Package: gnome* /kde/
Pin: release a=experimental
Pin-Priority: 500

The rule for those expressions? They can show up anywhere a string can show up. So this next pin gives priority 990 to all packages from a release starting with plucky 💅

Package: *
Pin: release n=plucky*
Pin-Priority: 990

Not me about to tell you the messy part 😭 If a regular expression shows up in a Package field, it behaves exactly like that regex got replaced with a list of every package name it matches. Is that gonna change someday? Genuinely undecided. So always list your wildcard pins first, so the later specific pins override it. And heads up: the pattern * in a Package field is not considered a glob(7) expression on its own.

Want to pin all binaries produced by the apt source package of this APT's version to 990? Say less:

Package: src:apt
Pin: version 3.3.5
Pin-Priority: 990

Source package pinning can be combined with regular expressions and glob patterns, and it can also take a binary architecture 👑

For example, let's pin every binary for every architecture produced by any source package that has apt in its name to 990:

Package: src:*apt*:any
Pin: version *
Pin-Priority: 990

That :any suffix is what makes sure it grabs binary packages from any architecture. Skip the suffix and apt implicitly assumes :native, which — you guessed it — only selects packages from the native architecture 🙈

---

✨ How APT Interprets Priorities ✨

Priorities (P) that you assign in the APT preferences file have to be positive or negative integers, no cap. Here's roughly how apt reads them:

• P >= 1000 — a version gets installed even if that means downgrading the package 💀
• 990 <= P < 1000 — a version gets installed even if it doesn't come from the target release, unless the installed version is more recent
• 500 <= P < 990 — a version gets installed unless there's a version available belonging to the target release, or the installed version is more recent
• 100 <= P < 500 — a version gets installed unless there's a version available belonging to some other distribution, or the installed version is more recent
• 0 < P < 100 — a version gets installed only if there's no installed version of the package
• P < 0 — prevents the version from being installed, blocked, not today 🚫
• P = 0 — has undefined behaviour. Do not use it. Periodt.

So the first specific-form record that matches an available package version is the one that determines that version's priority. And if that doesn't happen? Then the package's priority is the maximum of all the priorities defined by generic-form records matching that version. And any records defined using patterns in the Pin field other than *? Those get treated like specific-form records, iykyk.

Let's do an example 💖 Suppose the APT preferences file has these three records we showed earlier:

Package: perl
Pin: version 5.32*
Pin-Priority: 1001

Package: *
Pin: origin ""
Pin-Priority: 999

Package: *
Pin: release unstable
Pin-Priority: 50

Then, bestie:

• The most recent available version of the perl package will be installed, so long as that version's version number begins with 5.32. And if any 5.32* version of perl is available while the installed version is 5.36*, then perl gets downgraded 😭
• A version of any package other than perl that's available from the local system outranks other versions — even versions belonging to the target release 👑
• A version of a package whose origin isn't the local system but some other site listed in sources.list(5), and which belongs to an unstable distribution, only gets installed if it's selected for installation and no version of the package is already installed 🌸

---

🦋 Determination of Package Version and Distribution Properties 🦋

The locations listed in the sources.list(5) file should be handing over Packages and Release files to describe the packages available at that location, fr fr.

The Packages file is normally found in the directory .../dists/dist-name/component/arch — for example, .../dists/stable/main/binary-i386/Packages. It's a series of multi-line records, one for each package available in that directory. And out of each whole record, only two lines actually matter for setting APT priorities:

• the Package: line — gives the package name 💅
• the Version: line — gives the version number for the named package

The Release file is normally found in the directory .../dists/dist-name: for example, .../dists/stable/Release, or .../dists/trixie/Release. It's a single multi-line record that applies to all the packages in the directory tree below its parent. And unlike the Packages file, basically all of the lines in a Release file are relevant for setting APT priorities 👀

• the Archive: or Suite: line — names the archive that all the packages in the directory tree belong to. For example, the line Archive: stable or Suite: stable specifies that all the packages in the directory tree below the parent of the Release file are in a stable archive. To specify this value in the APT preferences file you'd need the line:

Pin: release a=stable

• the Codename: line — names the codename that all the packages in the directory tree belong to. For example, the line Codename: forky specifies that all the packages in the directory tree below the parent of the Release file belong to a version named forky. To specify this value in the APT preferences file you'd need the line:

Pin: release n=forky

• the Version: line — names the release version. For example, the packages in the tree might belong to Debian release version 13. Note that there's normally no version number for the testing and unstable distributions, because they haven't been released yet 🙈 To specify this in the APT preferences file you'd need one of the following lines:

Pin: release v=13
Pin: release a=stable, v=13
Pin: release 13

• the Component: line — names the licensing component associated with the packages in the directory tree of the Release file. For example, the line Component: main specifies that all the packages in the directory tree are from the main component, which entails that they're licensed under terms listed in the Debian Free Software Guidelines. To specify this component in the APT preferences file you'd need the line:

Pin: release c=main

• the Origin: line — names the originator of the packages in the directory tree of the Release file. Most commonly this is Debian. To specify this origin in the APT preferences file you'd need the line:

Pin: release o=Debian

• the Label: line — names the label of the packages in the directory tree of the Release file. Most commonly this is Debian. To specify this label in the APT preferences file you'd need the line:

Pin: release l=Debian

All the Packages and Release files retrieved from locations listed in the sources.list(5) file get stored in the directory /var/lib/apt/lists, or in the file named by the variable Dir::State::Lists in the apt.conf file 🎀 For example, the file debian.lcs.mit.edu_debian_dists_unstable_contrib_binary-i386_Release contains the Release file retrieved from the site debian.lcs.mit.edu for binary-i386 architecture files from the contrib component of the unstable distribution ✨

---

🎀 Optional Lines in an APT Preferences Record 🎀

Each record in the APT preferences file can optionally begin with one or more lines beginning with the word Explanation:. It's literally just a spot for comments, bestie 💬

🌸 EXAMPLES 🌸

ok bestie these are the moment, the actual recipes, the "just copy-paste it and slay" section 💅

---

🎀 Tracking Stable 🎀

so like, this preferences file right here? it makes APT give every package version from a stable distribution a priority higher than the default (500), and then hits everything from other Debian distributions with a priority so low it's basically a "do not perceive her" 💀

Explanation: Uninstall or do not install any Debian-originated
Explanation: package versions other than those in the stable distro
Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

and with a suitable sources.list(5) file plus that preferences file up there? any of these commands will make APT upgrade to the latest stable version(s), no cap:

apt-get install package-name
apt-get upgrade
apt-get dist-upgrade

but this next one is different energy — it upgrades the specified package to the latest version from the testing distribution, and then... it just stays there. the package will not be upgraded again unless you run this command again. one-time thing, it's giving limited edition ✨

apt-get install package/testing

---

🦋 Tracking Testing or Unstable 🦋

ok this one's the multitasker. this preferences file gives package versions from testing a high priority, versions from unstable a lower priority, and versions from other Debian distributions a prohibitively low priority:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 800

Package: *
Pin: release o=Debian
Pin-Priority: -10

with a suitable sources.list(5) file and that preferences file, any of these commands will cause APT to upgrade to the latest testing version(s):

apt-get install package-name
apt-get upgrade
apt-get dist-upgrade

annnnd this one's the plot twist 👀 it upgrades the specified package to the latest version from the unstable distribution. thereafter, apt-get upgrade will upgrade the package to the most recent testing version if that's more recent than the installed version, otherwise to the most recent unstable version if that's more recent than the installed version. obsessive behaviour, honestly, but it works 🫶

apt-get install package/unstable

---

🌈 Tracking the evolution of a codename release 🌈

this is the "I'm following a name, not a vibe" edition. this preferences file assigns a priority higher than the default (500) to all package versions belonging to a specified codename of a distribution, and a prohibitively low priority to package versions belonging to other Debian distributions, codenames and archives.

heads up bestie: with this APT preference, APT will follow the migration of a release from the archive testing to stable and later oldstable. so if you instead want to follow, like, the progress in testing notwithstanding the codename changes, you should use the example configurations above. iykyk 💖

Explanation: Uninstall or do not install any Debian-originated package versions
Explanation: other than those in the distribution codenamed with forky or sid
Package: *
Pin: release n=forky
Pin-Priority: 900

Explanation: Debian unstable is always codenamed with sid
Package: *
Pin: release n=sid
Pin-Priority: 800

Package: *
Pin: release o=Debian
Pin-Priority: -10

with a suitable sources.list(5) file and that preferences file, any of these commands will cause APT to upgrade to the latest version(s) in the release codenamed with forky:

apt-get install package-name
apt-get upgrade
apt-get dist-upgrade

and finally, this one upgrades the specified package to the latest version from the sid distribution. thereafter, apt-get upgrade will upgrade the package to the most recent forky version if that's more recent than the installed version, otherwise to the most recent sid version if that's more recent than the installed version. the way it just keeps checking 😭 iconic.

apt-get install package/sid

---

⭐ FILES ⭐

• /etc/apt/preferences — the version preferences file. this is where you'd specify "pinning", i.e. a preference to get certain packages from a separate source or from a different version of a distribution. configuration item: Dir::Etc::Preferences.
• /etc/apt/preferences.d/ — file fragments for the version preferences. configuration item: Dir::Etc::PreferencesParts. drop your lil snippets in here, very main character of them 💅

---

🦋 SEE ALSO 🦋

apt-get(8) apt-cache(8) apt.conf(5) sources.list(5)

go read those too, they're the supporting cast and they ate 🎀

---

💀 BUGS 💀

found a bug? APT bug page[1] is the place. and if you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command. be nice to the maintainers, they're doing their best 🫶

---

👑 AUTHOR 👑

APT team

(no notes, we stan.)

---

💜 NOTES 💜

1. APT bug page https://bugs.debian.org/src:apt

---

okay that's the whole page, you're officially an apt_preferences scholar now, go forth and pin responsibly 🌸✨ this little beauty is from APT 3.3.5, dated 16 December 2025, and it's the APT_PREFERENCES(5) manual page — mwah, love you, bye 💖🎀🦋