APT preferences & debian-pinning [Solved]

[SilverX]

I recently realized that very little thought is given to APT's inner configuration by most distributions. Many users have unintentionally rendered their systems unusable because APT, due to a lack of proper configuration, mistakenly identifies critical packages as unnecessary and removes them—leading to catastrophic consequences.

This insight came to me while working on improving Entropy Linux to prevent it from breaking after a full system upgrade or encountering major issues when installing packages with Debian testing repositories enabled. During this process, I discovered two critical configuration files for APT that can drastically improve system stability:

/etc/apt/preferences
/etc/apt/preferences.d/debian-pinning
With these configurations properly set, APT transforms from a system prone to sudden failure into a robust package manager capable of handling multiple repository types (e.g., stable, testing, unstable, MX) simultaneously. It mitigates risks such as conflicting package versions or breaking crucial components like glibc6 during a full upgrade.

This improvement isn't hypothetical—I’ve experienced system-breaking updates on MX Linux and other distributions when attempting a simple apt update && apt upgrade. Such issues were especially frequent when a significant number of packages needed upgrading due to the lack of recent ISOs with updated packages.

Since implementing these configurations for Entropy, I’ve conducted numerous full upgrades with testing repositories enabled at all times. Additionally, I can now seamlessly specify which repository to use for individual packages using the -t flag. For example: sudo apt install -t testing <package>
This allows me to install newer versions from testing without hassle or risk. The difference is remarkable, and it’s a change I believe could benefit many others.

> /etc/apt/preferences

Code: Select all

# High priority for Debian Stable (Bookworm)
Package: *
Pin: release a=bookworm
Pin-Priority: 1001

# Security updates for Stable (Bookworm) with the same high priority
Package: *
Pin: release n=bookworm-security
Pin-Priority: 1001

# Medium priority for Debian Testing (Trixie)
Package: *
Pin: release a=trixie
Pin-Priority: 750

# Low priority for Debian Testing (to prevent auto-installation)
Package: *
Pin: release a=testing
Pin-Priority: 50

# Very low priority for Debian Unstable (Sid)
Package: *
Pin: release a=unstable
Pin-Priority: 1

# Extremely low priority for Debian Experimental
Package: *
Pin: release a=experimental
Pin-Priority: -1

# Medium priority for Debian Backports (Bookworm-Backports)
Package: *
Pin: release a=bookworm-backports
Pin-Priority: 500

# High priority for MX Linux Repositories (Main)
Package: *
Pin: origin nl.mxrepo.com
Pin-Priority: 1002

And
> /etc/apt/preferences.d/debian-pinning

Code: Select all

# High priority for Debian Stable (Bookworm)
Package: *
Pin: release o=Debian, a=bookworm
Pin-Priority: 1001

# High priority for Debian Stable Updates (Bookworm Updates)
Package: *
Pin: release o=Debian, a=bookworm-updates
Pin-Priority: 1001

# High priority for Debian Stable Security Updates (Bookworm Security)
Package: *
Pin: release o=Debian, n=bookworm-security
Pin-Priority: 1001

# Medium priority for Debian Testing (Trixie)
Package: *
Pin: release o=Debian, a=trixie
Pin-Priority: 750

# Low priority for Debian Testing (general)
Package: *
Pin: release o=Debian, a=testing
Pin-Priority: 400

# Very low priority for Debian Unstable (Sid)
Package: *
Pin: release o=Debian, a=unstable
Pin-Priority: 100

# Extremely low priority for Debian Experimental
Package: *
Pin: release o=Debian, a=experimental
Pin-Priority: 1

# Medium priority for Debian Backports (Bookworm Backports)
Package: *
Pin: release o=Debian, a=bookworm-backports
Pin-Priority: 500

# High priority for MX Linux Repositories (Main)
Package: *
Pin: origin nl.mxrepo.com
Pin-Priority: 1002

It's surprising that no one has thought to include this in their default distro configuration. If the omission is intentional for reasons such as minimalism, simplicity, or promoting user responsibility, these arguments no longer hold up in practice. Including this configuration requires only 1,949 bytes of storage, and its sole impact—whether intentional or not—is enabling the proper functionality of APT as originally designed. This prevents the package manager from inadvertently entering a "self-destruct" mode due to hidden or sudden issues.

It’s reasonable to assume that most users are sufficiently advanced while maintaining the principle of user responsibility for their systems. Common counterarguments, such as "it only happens if you mess with it," or "testing repositories are inherently unstable," are familiar refrains from staunch advocates of the traditional "vanilla" Debian approach.

In practice, however, using testing and unstable repositories while installing packages from these sources has significantly improved the stability of APT in my system. It has made Entropy Linux more resilient to issues than Debian, MX Linux, or any other Debian-based distro I’ve encountered. Astonishingly, less than 2 KB of carefully considered configuration can address one of Debian’s most significant issue and protect users from learning painful lessons the hard way.

This approach benefits everyone, particularly less experienced users who are prone to experimenting with APT—whether by attempting to install newer packages, running outdated or unverified commands from the internet, or inadvertently breaking their system. These scenarios are common and will continue to happen.

So, why not include these by default?

[fehlix]

This improvement isn't hypothetical—I’ve experienced system-breaking updates on MX Linux ...

We do strongly recommend not to adding randomly other repos, from other the distributions.
If you do, you have to prepare something like you propose, in order to "try" avoid breaking the system and keeping and taking the pieces home.

[SilverX]

Actually, MX broke on me few times on pretty much fresh install while doing full apt upgrade with +300 upgradable packages, with zero involvment from my side, nor even touching repos.
And by other repos, I mean debian sid and trixie.

Don't get me wrong, MX Is amazing distibution, that I still have special place in my heart for!

Although facts are it would be that tiny bit better with APT config.
Regardless if you'll use what I provided, or will write one yourself, I strongly reccomend doing so.
I can tell both from research and personal experience it does matter if you configure packages, especially as important as apt is.

[asqwerth]

Actually, MX broke on me few times on pretty much fresh install while doing full apt upgrade with +300 upgradable packages, with zero involvment from my side, nor even touching repos.
And by other repos, I mean debian sid and trixie.

Don't get me wrong, MX Is amazing distibution, that I still have special place in my heart for!

Although facts are it would be that tiny bit better with APT config.
Regardless if you'll use what I provided, or will write one yourself, I strongly reccomend doing so.
I can tell both from research and personal experience it does matter if you configure packages, especially as important as apt is.

Without terminal output I'm a bit skeptical about there having been 300+ (!) upgradable packages on a vanilla install without the adding of other repos. I'm not sure what you mean by "without touching repos". Does that mean you did add these other repos or perhaps manually installed deb files, but did not tweak the apt preferences?

The way MX wishes to operate is to stay binary compatible with Debian Stable, so no adding of Debian Testing or Sid repos. If newer packages are needed from Testing and Sid, our packaging team backports the newer packages to be compatible with Debian Stable.

I notice you keep namedropping that Debian distro in your posts. Not sure if it's your own project or what. Perhaps you don't mind that distro install being a FrankenDebian, and perhaps you are adept enough to sort things out on your own install, but MX is specifically Debian Stable-based.

[DukeComposed]

Without terminal output I'm a bit skeptical about there having been 300+ (!) upgradable packages on a vanilla install without the adding of other repos.

On a lark, I booted an MX-23.2 ISO I had laying around and let MX Updater/apt-notifier check to see how behind it was. It let me know there were 383 new updates to apply. (337 to upgrade, 46 new packages to install, and 1 to remove.) 23.2 is about 11 months out of date, which isn't unheard of if someone intends to install an existing ISO they have and patch it to 23.4.

Perhaps you don't mind that distro install being a FrankenDebian, and perhaps you are adept enough to sort things out on your own install, but MX is specifically Debian Stable-based.

What stood out to me is the statement "MX broke on me few times on pretty much fresh install while doing full apt upgrade" which means running an "apt full-upgrade"/"apt-get dist-upgrade" and hoping for the best. From man apt-get(8), which of course we all have memorized:

Code: Select all

dist-upgrade in addition to performing the function of upgrade, also intelligently
handles changing dependencies with new versions of packages; apt-get has a "smart"
conflict resolution system, and it will attempt to upgrade the most important packages
at the expense of less important ones if necessary. The dist-upgrade command may
therefore remove some packages.

dist-upgrade does exactly what it says on the tin: it will prioritize the big stuff at the risk of the little stuff, and delete things in the process if it sees a conflict. This matches what OP describes, but it's not something I've encountered in my years of upgrading MX, in part because of the Debian policy of keeping the same libraries and utilities for the lifetime of a release. Big breaking changes are typically put into an upcoming Debian release, so when I say "upgrading MX" I mean only running "apt-get upgrade". MX-21 installs stay at MX-21. I don't edit the apt sources to try to turn an MX-21 machine into MX-23, which dist-upgrade will try to do if you let it. Part of me thinks that when OP says "And by other repos, I mean debian sid and trixie", that means trying to dist-upgrade an old MX major release to a new one.

[asqwerth]

Mx-updater uses apt full-upgrade by default. I've not had any issues.

I guess 300+ updates is possible for an old iso. On the other hand, I've waited almost a year before upgrading mx on my dad's netbook and my old laptop in the past without issue. I've never had conflict issues with Debian stable even if I've not updated my system for a long time. I always use apt full-upgrade.

[anticapitalista]

Broken/un-updated package mirrors may also cause breakage.
Whenever there is a big upgrade, I always check that the default repos are working as they should.

[fehlix]

Actually, MX broke on me few times on pretty much fresh install while doing full apt upgrade with +300 upgradable packages, with zero involvment from my side, nor even touching repos.

So how many 3trd party, or ubuntu-like "foreign" deb-package have you installed, before the system broke?
Note: Even one innocent looking package, which even may work for a while, can cause a system to break - suddenly - after a big system upgrade.

[asqwerth]

@DukeComposed

It should be noted that apt-upgrade will only install updates that don't remove other packages or that don't install additional packages.

So if you used apt upgrade instead of apt full-upgrade, you won't pull in any new mx tools that are added in the course of the life of the release, nor will it install any upgraded packages that need new libraries /dependencies to be installed.

MX-updater has been apt full-upgrade or apt-get dist-upgrade all this time.

[fehlix]

@DukeComposed

It should be noted that apt-upgrade will only install updates that don't remove other packages or that don't install additional packages.

So if you used apt upgrade instead of apt full-upgrade, you won't pull in any new mx tools that are added in the course of the life of the release, nor will it install any upgraded packages that need new libraries /dependencies to be installed.

MX-updater has been apt full-upgrade or apt-get dist-upgrade all this time.

Good, you mentioned that. The option "dist-upgrade" is certainly a misnomer, they replaced it later with "full-upgrade" (though keeping the old option name). Maybe they missed to change "upgrade" to something like "partial-upgrade".