The Definitive
Debian Deep Dive
History, governance, the three-suite release pipeline, migration mechanics, security pockets, LTS, ELTS — every layer of how one of the world's oldest actively maintained community Linux distributions works, from Ian Murdock's 1993 announcement to the extended lifecycle programmes of today.
Origins: How Debian Was Born (1993)
On August 16, 1993, a 20-year-old computer science student named
Ian Murdock posted a brief message to the comp.os.linux.development
Usenet group announcing a new Linux distribution he planned to build. The name was a
portmanteau of his then-girlfriend (later wife) Debra and his own first name —
Debra + Ian = Debian.
The original announcement read: "This is just to announce the imminent completion of a brand-new Linux release, which I'm calling the Debian Linux Release. This is a release that I have put together basically from scratch." Murdock envisioned something fundamentally different — a distribution built openly, by the community, not by a commercial entity.
Linux itself was only two years old at the time. Most distributions in 1993 were simple tarballs of the kernel plus a minimal userland. Ian wanted Debian to be different: properly maintained, with an open development process. He published the Debian Manifesto in January 1994, outlining the philosophy that the distribution would be made non-commercially and would be maintained with great care.
The Debian Social Contract & DFSG
In 1997, as Debian grew to hundreds of volunteers, it needed a formal statement of values. Bruce Perens — who would later co-found the Open Source Initiative — drafted the Debian Social Contract, a commitment by the Debian Project to its users and to the free software community. The current Social Contract is still built around five core commitments:
- 01 Debian will remain 100% free.
- 02 Debian will give back to the free software community.
- 03 Debian will not hide problems — the Bug Tracking System is public.
- 04 Debian's priorities are its users and free software (in that order over commercial interests).
- 05 Works that do not meet Debian's free-software standards are not part of Debian, but can be made available in separate areas such as non-free and non-free-firmware.
Alongside the Social Contract, Perens also wrote the
Debian Free Software Guidelines (DFSG), a set of criteria that a
software licence must satisfy to be considered "free." The DFSG became the basis for the
widely-adopted Open Source Definition when the OSI was founded in 1998.
Every package in Debian's main archive must comply with the DFSG to this day.
A licence is DFSG-free if it allows: free redistribution, access to source code, derived works, integrity of author's source, no discrimination against persons/groups/fields of endeavour, and applies uniformly to all who receive the software. GPL, MIT, Apache 2.0 — all DFSG-compliant. Non-free: proprietary firmware blobs, Creative Commons NC/ND.
The Archive Structure — main, contrib, non-free, non-free-firmware
Debian's archive is split into distinct components, reflecting the Social Contract:
| Component | DFSG-free? | Deps on non-free? | Supported by Debian | Examples |
|---|---|---|---|---|
| main | ✓ Yes | No | ✓ Fully | bash, nginx, gcc, dpkg |
| contrib | ✓ Yes | Yes (needs non-free) | ⚠ Best effort | steam-installer |
| non-free | ✗ No | — | Not part of Debian; limited/best-effort support | unrar, ttf-mscorefonts |
| non-free-firmware | ✗ No | — | Not part of Debian; distributed to support hardware enablement | firmware-iwlwifi, firmware-amd-graphics |
Starting with Bookworm (Debian 12) in 2023, non-free-firmware
was split off as a separate component (previously it was part of non-free).
Crucially, the official Debian installer images now include non-free-firmware by default,
dramatically improving hardware support out of the box — a major pragmatic shift after decades
of strict policy debate.
Debian's Governance Model
Debian is not a company. It is a volunteer-driven meritocracy of over 1,000 active Debian Developers (DDs) and a larger number of Debian Maintainers (DMs). Understanding its structure helps explain why releases take the time they do.
Debian Project Leader (DPL)
Every year, Debian Developers elect a Debian Project Leader via a Condorcet-method vote. The DPL has broad authority to represent Debian externally, make decisions within their mandate, and delegate powers. However, they cannot override the Debian Constitution or decisions made by the Technical Committee.
Technical Committee
The Technical Committee (TC) makes binding decisions on technical policy disputes that cannot be resolved within teams. It is the court of last resort for technical disagreements. The TC consists of ~8 experienced DDs and is a deliberately slow, deliberate body.
Key Teams
| Team | Responsibility |
|---|---|
| ftpmaster | Controls the archive — accepts/rejects new packages, manages the NEW queue, manages transitions |
| Release Team | Manages the freeze, migration from Testing to Stable, sets the release schedule |
| Security Team | Issues DSAs (Debian Security Advisories), maintains stable-security pocket |
| LTS Team | Extends security support beyond the Security Team's mandate (separate, partially funded) |
| DAM | Debian Account Managers — new developer applications, NM process |
| DSA | Debian System Administrators — manages Debian's own infrastructure |
| Installer Team | Develops and maintains debian-installer (d-i) |
Becoming a Debian Developer
The New Member (NM) process is extensive by design. An aspiring DD must find an advocate (an existing DD), pass a philosophy and procedures check (demonstrating understanding of the Social Contract, DFSG, Policy), pass a tasks and skills check (demonstrating packaging knowledge), and be approved by the DAM. This process can take months to years and ensures only committed, knowledgeable people gain upload rights to the archive.
Since 2007, the Debian Maintainer role provides a lighter-weight path: DMs can upload packages they maintain without full DD sponsorship, but cannot upload arbitrary packages. It is a stepping stone toward full DD status.
The Three-Suite Pipeline
Debian's most distinctive characteristic is its three-suite rolling pipeline. At any given moment, three primary suites exist in the archive simultaneously, each serving a different purpose and risk profile:
Where all new and updated packages enter. Never "released." Maximum freshness, maximum risk.
Packages that survive Sid without critical bugs migrate here automatically. Future stable.
Snapshot of Testing after a full freeze. Only security and critical bug fixes.
Think of it as a quality filter: packages are born in Unstable (the rawest form), promoted to Testing (a proving ground), and eventually frozen into Stable (the production-ready artifact). There is also a fourth suite, Experimental, which sits upstream of Unstable and is used for packages too unstable even for Sid.
manual
upload
Britney
auto
freeze +
release
When a new stable is released, the previous stable becomes oldstable (currently Bookworm). It receives continued security support — from the Debian Security Team initially, then handed to the LTS team — for the remainder of its Debian lifecycle. Older releases can remain available through LTS or commercial ELTS, but they are no longer the normal production target.
oldoldstable is the stable release before oldstable. During Trixie's lifetime,
Bullseye is the oldoldstable-generation release and is handled through LTS rather than normal
Security Team support. In documentation and automation, prefer the codename (bullseye,
bookworm, trixie) when you mean a specific release, because moving aliases
change meaning after each stable release.
Unstable — The Engine Room
Why Is It Called "Sid"?
All Debian release codenames come from characters in the Pixar film Toy Story (more on the full naming scheme in the timeline section). Sid is the toy-destroying neighbour kid — and Unstable is permanently named Sid because it will never be released. It always destroys things (breaks packages). The name is an inside joke with a sharp technical truth: Unstable is perpetually churning and is never stabilized into a release.
What Happens in Sid
When a Debian Developer uploads a new or updated package, it lands in Sid directly (with one important exception: brand-new packages go through the NEW queue first).
The NEW Queue
When a package appears in the Debian archive for the first time, or when a package adds a new binary that didn't exist before, it is placed in the NEW queue awaiting review by an FTP Master. This review checks licensing compliance (DFSG), correct section classification, and basic policy adherence. Only after acceptance does the package enter Sid and become installable.
Autobuilders (buildd)
Debian's archive spans many architectures, but the current Stable release architecture set is
smaller than in older releases. For Debian 13 new installations, the normal installer targets are
amd64, arm64, armhf, ppc64el, riscv64, and s390x. i386 is no longer a regular
standalone architecture: there is no Debian 13 installer or official kernel for i386 systems;
it is retained for running legacy 32-bit userland on amd64 through multiarch or chroots.
armel remains a limited legacy/upgrade path rather than a normal new-install target.
When a source package is uploaded to Sid,
the buildd network automatically compiles it for the relevant architectures.
Missing builds, outdated binaries, or failures to build from source can block migration to
Testing and may become release-critical depending on the package and architecture impact.
Lintian
Before uploading, maintainers run Lintian, Debian's package checker, which enforces hundreds of policy rules and detects common mistakes. Certain Lintian errors are blockers; others are warnings. The tool is part of what keeps Debian's packaging quality uniformly high.
Who Uses Sid?
Running Sid as your primary system is for experienced Debian contributors and adventurous users who want the absolute latest packages and who can deal with occasional breakage. On any given day, Sid might have:
- ⚠ Dependency conflicts during transitions (e.g., a new Python or GCC version where half the ecosystem has been rebuilt and half hasn't)
- ⚠ Packages broken by an API change upstream that maintainers haven't patched yet
- ⚠ Missing libraries because a dependency was removed or renamed
A transition occurs when a shared library changes its ABI or a core component (Python, Perl, GCC, Qt, Boost) changes its major version. Every reverse-dependency must be rebuilt in coordination. The Release Team tracks these in a transitions tracker. During a large transition (like a Python major version bump), Sid can be quite broken for days or weeks while all packages rebuild.
Experimental — Above Sid
Experimental is an optional overlay above Sid. Packages here are not automatically propagated anywhere — they require a maintainer to explicitly push them to Sid later. Experimental is used for:
- → Software with development snapshots or major API breaks (e.g., early GNOME 4x alpha)
- → Packages under active development where normal Sid propagation would block transitions
- → Packages requiring explicit user awareness before installation
# /etc/apt/sources.list — to enable Experimental
deb http://deb.debian.org/debian unstable main contrib non-free non-free-firmware
deb http://deb.debian.org/debian experimental main
# You still need to explicitly request experimental packages:
apt install -t experimental package-nameTesting — The Future Stable
Testing is the suite that will eventually become the next Stable release. It is automatically populated by a migration script called Britney, which runs daily and evaluates packages in Sid to determine if they are eligible to migrate.
Britney: The Migration Engine
Britney is not a simple timer — it is a constraint-solving system that evaluates a complex set of rules before promoting a package from Sid to Testing. A package in Sid must satisfy all of the following:
- R1The 10-day age threshold — For packages in key sections, the package must have been in Sid for at least 10 days (low-urgency packages: 10 days; medium: 5 days; high/critical: 2 days; emergency: 0 days). The urgency is set by the maintainer in the changelog.
- R2No new Release Critical bugs — The version in Sid must not introduce new RC bugs compared to the version currently in Testing. If the Sid version introduces an RC bug (severity: critical, grave, or serious), migration is blocked.
- R3Architecture state is acceptable — The source package's binaries must be built, up to date, or otherwise handled for the relevant release architectures. Missing builds, old binaries, and architecture removals can block migration.
- R4Dependencies satisfied — All packages that this package depends on must themselves be in Testing (or migrate simultaneously). Britney can perform "group migrations" where multiple interdependent packages migrate together as a set.
- R5No breakage of Testing — The migration must not make any package in Testing uninstallable. Britney models the full dependency graph of Testing and simulates the migration before committing it.
A Release Critical bug is a bug of severity critical,
grave, or serious in Debian's Bug Tracking System (BTS). RC bugs
block a package from migrating to Testing and ultimately block the release of the entire
distribution. One of the main activities leading up to a Debian release is a community-wide
"RC bug squashing" effort to get the RC bug count to zero.
The Freeze
When the Release Team decides it is time to prepare a new Stable release, they freeze Testing. The freeze proceeds in stages:
- 1Transition freeze — No new transitions may start in Sid that could affect Testing. Ongoing transitions must be completed or abandoned.
- 2Soft freeze — New packages can still migrate from Sid to Testing, but only if they don't introduce new features. Bug fixes and security fixes are allowed.
- 3Full freeze — No package can migrate to Testing without explicit Release Team approval via an unblock request. Only targeted bug fixes are allowed.
- 4Release — Testing is renamed to Stable. For example,
trixiebecame Debian 13 Stable on August 9, 2025;forkythen became the new Testing branch and package migration from Sid resumed.
Who Uses Testing?
Testing offers a middle ground: more current packages than Stable but more consistency than Sid. Many developers and advanced users run Testing as their daily driver. Key caveats:
- !Testing has no dedicated security-team coverage comparable to Stable. Fixes generally flow through Unstable and then migrate when policy allows, and the Testing release page explicitly warns that security updates are not managed by the Security Team in a timely way. A
testing-securitypocket may exist during the freeze/release-preparation period, but it is not equivalent to routine Stable security support. Do not use Testing for security-sensitive production systems. - !During a freeze, Testing becomes more conservative, but it is still a development branch. Treat it as suitable for development, validation, and advanced workstations — not as a substitute for Stable on production servers.
# sources.list for Testing
deb http://deb.debian.org/debian testing main contrib non-free non-free-firmware
# Or pin the current testing codename explicitly:
deb http://deb.debian.org/debian forky main contrib non-free non-free-firmwareStable — Production-Grade Debian
Stable is what most servers, appliances, and enterprise Debian deployments run. When Testing is frozen and all RC bugs are squashed, the Release Team performs the release: Testing is renamed to Stable. From that point, no new packages or version upgrades enter Stable — only security patches and critical bug fixes.
Point Releases
Stable releases have point releases (e.g., 13.0 → 13.1 → 13.2 → 13.5+). These are periodic snapshots that bundle together:
- →Security fixes that have been issued since the previous point release via the stable-security pocket
- →Proposed-updates — non-security fixes approved by the Release Team for high-impact bugs
- →Updated installation media (so new installs don't need to immediately download thousands of security updates)
Point releases happen periodically, often every few months, but not on a rigid calendar. As of this
review, Debian's official trixie release page lists Debian 13.5 as the current point release,
released on May 16, 2026. Running apt update && apt upgrade keeps a Stable system
fully current regardless of point release boundaries — point releases are primarily useful for
updated installer images.
The Codename System — Toy Story
Every Debian release since 1996 has been codenamed after a Toy Story character. This tradition was started by Bruce Perens, who was the Debian Project Leader at the time and was also a Pixar employee. The practice has continued ever since, making Debian releases instantly recognizable by their codenames.
Buzz → Rex → Bo → Hamm → Slink → Potato (not strictly Toy Story) → Woody → Sarge → Etch → Lenny → Squeeze → Wheezy → Jessie → Stretch → Buster → Bullseye → Bookworm → Trixie → … The names are drawn from all three films and spin-offs. Sid, as noted, is permanently Unstable. Buzz Lightyear was Debian 1.1 in 1996.
Stable's Archive Pockets
Stable is not a single monolithic repository. It is composed of several
suites/pockets, each serving a specific update category. Do not confuse these
with repository components such as main, contrib, non-free, and non-free-firmware.
| Purpose | Auto-updated by | Included in apt upgrade? | |
|---|---|---|---|
| stable | The stable base suite, updated through point releases; no normal feature churn. | — | ✓ |
| stable-security | Security fixes from the Debian Security Team. DSA-tagged. | Security Team | ✓ (if configured) |
| stable-proposed-updates (p-u) | Critical non-security bug fixes staged for the next point release. | Release Team (approved) | Opt-in |
| stable-updates | Time-sensitive non-security updates (e.g., timezone data, virus definitions) | Maintainers + Release Team | ✓ (if configured) |
| stable-backports | Newer versions of selected packages rebuilt for Stable. Less tested than Stable proper. | Backporters | Opt-in (pinning) |
stable-security in depth
The Debian Security Team maintains a separate infrastructure
(security.debian.org) for maximum speed in distributing security fixes.
When a CVE is reported against a package in Stable, the Security Team (or the
package maintainer) prepares a fix, and it is published as a
Debian Security Advisory (DSA). Security fixes follow a
"minimum diff" philosophy: only the exact patch for the vulnerability
is applied — no feature backporting, no version upgrades unless absolutely necessary.
# Recommended traditional sources.list for Stable (Trixie)
deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
# Optional: backports (note: needs explicit -t trixie-backports to install)
deb http://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmwarestable-backports in depth
Backports provide a way to get newer versions of specific software (e.g., a newer kernel, selected server tools, or newer userland utilities) without upgrading to Testing or Unstable. The package is normally taken from Testing and recompiled against the Stable base; in rare security-related cases a backport may be taken directly from Unstable. Backports have critical properties:
- →They are not installed by default. They require explicit APT pinning or
apt install -t trixie-backports package-name. - →They do not receive security support from the Debian Security Team (the backport maintainer is responsible).
- →They are considered less stable than the main Stable pocket — use them only for packages where you specifically need a newer version.
APT Sources: Codenames, Aliases, Components, and Safe Upgrades
Debian repository naming is one of the most important operational details for administrators.
A repository entry has three separate concepts that beginners often mix up: the
URI, the suite, and the components.
The suite can be a moving alias such as stable or a fixed codename such as
trixie. Components are the archive areas after the suite: main,
contrib, non-free, and non-free-firmware.
| Field | Example | Meaning | Operational Risk |
|---|---|---|---|
| URI | http://deb.debian.org/debian | Mirror or service endpoint. | Low; choose HTTPS or the CDN mirror service as appropriate. |
| Suite | trixie, trixie-updates, trixie-security | Which release or update pocket to track. | High; aliases move after releases. |
| Components | main contrib non-free non-free-firmware | Which license/support areas are enabled. | Medium; enabling non-free areas changes policy and support assumptions. |
Traditional sources.list format
# Debian 13 Stable, pinned to codename
deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
# Optional, use per package with -t trixie-backports
deb http://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmware
# Optional source package indexes, needed for apt source / build-dep workflows
deb-src http://deb.debian.org/debian trixie main contrib non-free non-free-firmwareDeb822 .sources format
Newer Debian systems also support the Deb822 source format in
/etc/apt/sources.list.d/*.sources. It is easier to read and safer to manage
with configuration management tools because each field is explicit.
Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Types: deb
URIs: http://security.debian.org/debian-security
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpgUse codenames on production systems. An entry using stable follows whatever
Debian currently calls stable. That is convenient for lab machines but dangerous for servers,
because a normal maintenance window after a release could unexpectedly become a major-release
upgrade.
deb entries fetch binary package indexes. deb-src entries fetch source
package indexes and are required for developer workflows such as apt source nginx
or apt build-dep nginx. On production servers, leave deb-src disabled
unless source retrieval or local package rebuilding is actually needed.
Safe major-release upgrade workflow
- 1Read the release notes first. Debian release notes document known upgrade hazards such as architecture support changes, obsolete packages, bootloader issues, and service-specific migrations.
- 2Fully update the current release. Bring Bookworm to its latest point release before upgrading to Trixie.
- 3Disable third-party repositories and old backports. Remove
bookworm-backportsentries before the upgrade; addtrixie-backportsonly after the system is on Trixie. - 4Change suites deliberately. Replace
bookworm,bookworm-updates, andbookworm-securitywithtrixie,trixie-updates, andtrixie-security. - 5Use the recommended APT sequence. Run
apt update, perform a minimal upgrade if required by the release notes, then useapt full-upgradefor the actual release transition. - 6Reboot and verify. Check kernel, services, logs, package holds, removed packages, and application-specific migration notes before calling the upgrade complete.
LTS — Long Term Support Lifecycle
Debian's security support lifecycle has expanded significantly over the years, partly in response to commercial demand and partly thanks to dedicated volunteer and sponsored effort. A Debian release receives roughly five years of Debian project security coverage: about three years from the Debian Security Team, followed by roughly two years of LTS. Commercial ELTS can extend selected releases further, commonly to a 10-year window from the original release.
Phase 1: Debian Security Team Support (~3 years)
From release day, the Debian Security Team provides active security support for Stable. This continues until approximately one year after the next stable release. For example, Debian 11 (Bullseye) was released August 2021; Debian 12 (Bookworm) was released on 2023-06-10; Bullseye regular security support ended on 2024-08-14, after which the LTS team took over.
During this phase, the Security Team issues Debian Security Advisories (DSAs) for critical vulnerabilities. These are industry-tracked advisories that enterprise users, SIEM systems, and compliance tools monitor.
Phase 2: Debian LTS (~years 4–5)
After the Security Team hands off, the Debian LTS team continues security support for approximately two more years, bringing total support to roughly 5 years from the original release date. The LTS team was founded in 2014, starting with Squeeze (6.0).
The Debian LTS effort is largely coordinated and partially funded by Freexian, a French consulting company founded by Raphaël Hertzog. Freexian allows companies to sponsor LTS work, which pays Debian contributors to fix security issues in older releases. This model is one reason Debian LTS has sustained coverage for widely used packages. Without it, maintaining 5-year support purely on volunteer basis would be unsustainable.
Key differences between Phase 1 and Phase 2 (LTS):
| Aspect | Phase 1 (Security Team) | Phase 2 (LTS Team) |
|---|---|---|
| Advisory label | DSA-XXXX (Debian Security Advisory) | DLA-XXXX (Debian LTS Advisory) |
| All packages? | Yes, all main packages | Popular/impactful packages only; a smaller subset |
| All architectures? | All release architectures | Reduced set; varies by release. For Bullseye LTS, Debian lists i386, amd64, armhf, and arm64; verify the LTS page for the exact release you operate. |
trixie-security for current Stable; bookworm-security for current oldstable |
Same codename-security pocket during the LTS period, where applicable | |
| Funding | Volunteer + Debian infrastructure | Freexian sponsors + volunteers |
Phase 3: ELTS (Extended LTS) — years 6–10
For the most conservative deployments (embedded systems, long-lifecycle appliances, infrastructure that simply cannot be upgraded), Freexian's Extended LTS (ELTS) provides a further 5 years of security support, bringing the total to 10 years or more from release, depending on the Freexian ELTS schedule and subscription scope.
ELTS is explicitly a commercial service, not an official Debian project:
- !Organizations must pay Freexian for ELTS support (it is not freely available).
- !Coverage is architecture-limited and varies by release and customer demand; do not assume it matches the original Stable architecture set.
- !Only a curated subset of critical packages is covered (web servers, OpenSSL, kernel, libc, databases — not the full archive).
- !Advisories are labelled ELA-XXXX (Extended LTS Advisory).
- !A special apt repository (
deb.freexian.com) is used, notsecurity.debian.org.
ELTS in Practice
To illustrate the lifecycle in practice — Debian 8 (Jessie, released April 2015) had its Debian Security Team support until mid-2018. LTS continued until June 2020 (5 years). ELTS via Freexian ran until June 2025 — a full 10-year span from release. An organization could theoretically run Jessie on amd64 servers with security patches through 2025.
Organizations accessing ELTS receive credentials from Freexian to access the
private apt repository. They configure /etc/apt/sources.list.d/ with the
provided endpoint, which delivers signed packages. Advisories are tracked at
security-tracker.debian.org and the Freexian ELTS tracker.
Lifecycle Summary Visualization
The following bars represent the three phases for recent releases. Widths are proportional to 10-year windows.
The bars are a schematic view of support phases, not a precise proportional date chart. Debian-published full-support and LTS dates are authoritative for current releases; ELTS is commercial, subscription-scoped, and should be treated as a possible planning option rather than an automatic Debian Project guarantee.
Every Debian Release — Toy Story to Today
Debian has followed the Toy Story naming convention since 1.1 (Buzz) in 1996. The initial 0.01 through 0.93 releases in 1993–94 predated the codename system.
stable points to trixie (Debian 13), testing points to forky, and unstable remains permanently sid. Bookworm is oldstable; Bullseye is the oldoldstable-generation release and is in LTS until 2026-08-31.
Quick Reference Cheatsheet
Sources.list Aliases
| Alias | Points to | Changes after release? |
|---|---|---|
| stable | Current stable (Trixie) | Yes — jumps to next release automatically |
| testing | Current testing (Forky) | Yes — follows next testing |
| unstable / sid | Always Sid | Never — always Sid |
| oldstable | Previous stable (Bookworm) | Yes — shifts after each release |
| oldoldstable | Stable release before oldstable (Bullseye generation, currently LTS) | Yes — shifts after each release |
| trixie | Debian 13 forever | No — pinned codename; current stable |
| bookworm | Debian 12 forever | No — pinned codename; current oldstable |
| forky | Debian 14 development branch | No — pinned codename; current testing |
Always use the codename (e.g., trixie) in
/etc/apt/sources.list for production servers, never stable.
Using the alias stable means your system could automatically begin
tracking the next release after a Debian release day — potentially pulling in thousands
of package upgrades unintentionally during a routine apt upgrade.
Common apt Commands in Context
# Install from backports
apt install -t trixie-backports linux-image-amd64
# Check which suite a package comes from
apt-cache policy nginx
# Show package metadata in a beginner-readable form
apt-cache show nginx
# Show available versions in configured repositories
apt list -a nginx
# See RC bugs for a package
bts show --mbox src:nginx
# Check if a CVE affects your installed version
dpkg -l openssl
# Then cross-reference security-tracker.debian.org
# Simulate an upgrade to see what would change
apt -s dist-upgrade
# Hold a package at its current version
apt-mark hold libc6Suite Comparison at a Glance
| Property | Stable | Testing | Unstable (Sid) |
|---|---|---|---|
| Package freshness | Frozen at release | ~1 week behind Sid | Latest available |
| Security support | ✓ Dedicated team (DSA) | ⚠ Indirect only | ✗ None |
| Breakage risk | Very low | Low–medium | Medium–high |
| Release cadence | ~2 years | Continuous | Continuous |
| Use for production? | ✓ Yes | ⚠ With caution | ✗ Expert only |
| Rolling? | No (point releases) | Yes (within cycle) | Yes (always) |
| RC bugs guaranteed? | None at release | Active squashing | Can have many |
Lifecycle Phases Recap
| Phase | Duration | Provider | Advisory Type | Cost |
|---|---|---|---|---|
| Full Security Support | ~3 years from release | Debian Security Team | DSA | Free |
| LTS | ~years 4–5 | Debian LTS Team + Freexian | DLA | Free (community) |
| ELTS | ~years 6–10 | Freexian (commercial) | ELA | Paid subscription |
For servers: run Stable with the codename pinned, enable
trixie-security and trixie-updates, use backports
selectively for kernel or critical tools. Plan OS upgrades before your release
falls into LTS-only. For anything requiring 5+ year lifetime, budget for ELTS or
plan a migration path. Never run stable alias in production sources.list.
No comments:
Post a Comment