Dear Cloud Team,

The current amd64 genericcloud image installs packages that exist only in
stable-updates. Because stable-updates is documented as an opt-in suite, an
otherwise reasonable configuration -- stable + stable-security only -- leaves
those packages stranded above anything the enabled suites provide, and apt
then refuses to install anything depending on them.

I would like to suggest building images with stable-updates disabled while
still shipping it enabled in the image's sources.list.

Image tested: debian-13-genericcloud-amd64, build 20260819-2575 (Debian 13.6)


THE INCONSISTENCY
-----------------

Read directly from the pristine qcow2 (never booted), the image ships:

  /etc/apt/sources.list.d/debian.sources
    Suites: trixie trixie-updates trixie-backports
    Suites: trixie-security

That is a sensible default and I am not asking for it to change. However, the
image was also *built* with trixie-updates enabled, so it has these installed:

  python3.13             3.13.5-2+deb13u4
  python3.13-minimal     3.13.5-2+deb13u4
  libpython3.13-stdlib   3.13.5-2+deb13u4
  libpython3.13-minimal  3.13.5-2+deb13u4

trixie/main only carries 3.13.5-2+deb13u3, and per ftp-master madison, u4 is
present only in proposed-updates and stable-updates -- it is in neither stable
nor stable-security.

Note also that /etc/cloud/cloud.cfg sets "preserve_sources_list: true", so
cloud-init will not reconcile this at first boot.


REPRODUCING
-----------

On a stock image, comment out or remove the trixie-updates suite, then:

  # apt-get update
  # apt-get install python3-dev

  The following packages have unmet dependencies:
   libpython3.13-dev : Depends: libpython3.13-stdlib (= 3.13.5-2+deb13u3) but 3.13.5-2+deb13u4 is to be installed
                       Depends: libpython3.13 (= 3.13.5-2+deb13u3) but it is not going to be installed
   python3.13-dev : Depends: python3.13 (= 3.13.5-2+deb13u3) but 3.13.5-2+deb13u4 is to be installed
                    Depends: libpython3.13 (= 3.13.5-2+deb13u3) but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.

The dependencies are strict equality, so apt cannot resolve this without
downgrading, which it will not do. Every package depending on libpython3.13
becomes uninstallable.


WHY I THINK THIS IS WORTH CHANGING
----------------------------------

1. https://wiki.debian.org/StableUpdates frames the suite as opt-in ("To
   install packages from stable-updates, you can add an entry to your
   sources.list"), and describes its content as changes "not of a security
   nature", all of which "will be included in a later point release".

2. Because stable-security remains enabled during the build, building without
   stable-updates would still produce a fully security-patched image. The
   delta is non-security by definition.

3. Enabling a suite is always safe; disabling one is safe only if nothing
   installed came from it -- and the image gives the user no way to know that.
   The resulting error names neither stable-updates nor any suite, so the
   cause is genuinely hard to find. It took me a while.

4. At the time of writing, trixie-updates contains 19 binary packages from
   just two sources: python3.13 (18 binaries) and libdatetime-timezone-perl.
   So the change is narrow in practice.


SUGGESTED FIX
-------------

During the FAI build, install with stable + stable-security only, then write
the shipped sources.list with stable-updates enabled as it is today.

  - Users on the default configuration are unaffected: they receive the
    stable-updates content on their first apt upgrade, as they do now.
  - Users who disable stable-updates get an image whose installed packages
    are fully satisfiable from the suites they have enabled.


TRADE-OFF, STATED PLAINLY
-------------------------

The base image would ship up to one point-release cycle behind on non-security
packages -- most notably timezone data, which is precisely the kind of thing
stable-updates exists for. Anyone running apt upgrade recovers it immediately,
but images used ephemerally without upgrading would carry staler tzdata than
they do today. I think that is the right trade, but it is your call, and I did
not want to present the change as free.


COUNTER-CASE (this is specific to recently built images)
--------------------------------------------------------

An older image is not affected, because its packages are *behind* stable
rather than ahead of it. Starting from build 20260112-2355 (Debian 13.3,
python3.13 3.13.5-2), disabling trixie-updates and trixie-backports, then
running a full-upgrade against stable + stable-security only, upgrades cleanly
to 13.6 with python3.13 at 3.13.5-2+deb13u3, and "apt install python3-dev"
resolves normally.

So the problem appears specifically in images built between point releases,
when stable-updates has accumulated content that stable does not yet have.


DIAGNOSTIC
----------

This lists any installed package whose version exceeds everything the enabled
suites offer. It is empty on a healthy system:

  dpkg-query -W -f='${Package} ${Version}\n' | while read -r p v; do
    m=$(apt-cache madison "$p" 2>/dev/null \
        | awk -F'|' '{gsub(/ /,"",$2);print $2}' | grep -v '^$' \
        | sort -V | tail -1)
    [ -n "$m" ] && dpkg --compare-versions "$v" gt "$m" \
      && echo "STRANDED: $p $v > $m"
  done

(apt-cache policy cannot be used for this: when apt declines to downgrade it
reports the installed version as the Candidate, so the discrepancy is hidden.)

Please retitle or adjust the severity as you see fit; I was unsure whether
this is better filed as wishlist.

Thanks for your work on the images.

Regards,
Madalin Ignisca

Where do you see stable-updates being documented as opt-in?  It's
enabled by default in new installs based on debian-installer.  It's also
listed as enabled in the sources.list for trixie shown in the release
notes at
https://www.debian.org/releases/trixie/release-notes/upgrading.en.html#adding-apt-internet-sources,
with no indication of it being optional.

noah

https://wiki.debian.org/StableUpdates

It does not state that it is required either, and the wording suggests it is an opt-in to enable.

Look, I have been running for years servers by disabling stable-updates.

Provided very rock solid stable predictable upgrades, every ~2 months the minor release upgrade, and continuous security updates.

Please read all the text I wrote also, I tried to explain clearly, and maybe I should try to explain it again:

If you do 13.6 exact release, does it means it should contain already packages that have been updated in stable-updates after the day of release? Because for cloud image this is what happened.

And it can be tested. Start a fresh vm from 13.6 cloud image, disable updates, and all python dependent software fails to install.

The way I understood for years Debian repos is:

Stable - base, mandatory
Security - critical, required 100% in under certification environments
Updates - proposed updates, not security, that are nice to have, an opt-in if you accept possible every day updates available.

Disabling stable-updates, makes upgrades on a system more predictable, easier to trust, and less verbose for environments where I have to create tickets with list of all packages that will be included.

Is my logic wrong, to build a cloud image that if states 13.6, it will have packages 100% from 13.6 and ideally the last security updates that were until the process starts?

The wiki is not official documentation.  All official documentation I've
seen indicates stable-updates is active by default (i.e. is not
"opt-in").

Debian-installer activates and installs packages from stable-updates by
default at installation time.

We follow the d-i behavior with our default installation and will
continue to do so.

Yes, that is the expected behavior.  Similarly, it should contain all
packages from stable-security released since the latest point release.

That is an inaccurate understanding.  Stable-updates is not "proposed
updates" or "nice to have", nor is it any less controlled than the
security repository.  Stable updates are targeted changes that fix
critical issues and need to be adopted in a timely manner without
waiting for the next stable update.  Updates published via this
repository are published by the stable release managers and accompanied
by an announcement to debian-stable-announce@lists.debian.org, similar
to security updates being accompanied by a DSA to
debian-security-announce.

It's a fairly common occurrence for us to publish new cloud images
specifically to pick up changes published via stable-updates, for
example the systemd update from SUA 275
(https://lists.debian.org/debian-stable-announce/2025/09/msg00002.html).

And the recent python3.13 updated from stable-updates that you mentioned
in your original mail is specifically targeted to address a regression
introduced in the most recent point release that can cause python to
crash.  It is described in SUA 285 at
https://lists.debian.org/debian-stable-announce/2026/07/msg00003.html.

Many of the packages in the cloud images need to be updated within the
image in order to fully take effect. For example, the systemd issue
noted above refers to a crash *during provisioning*. The admin couldn't
rely on apt to install package updates post-provisioning.  Similarly,
there are multiple python processes invoked during the cloud image boot.
I don't believe it's the case here, but if the above python3.13
regression caused those services to crash, we could not expect users to
install the updates during or after the provisioning process.  The
updates need to be included in the image.

noah

Hi,

* Madalin Ignisca <hi@madalin.me> [260826 16:19]:

The text on this page was written with technically- and
historically-colored glasses a long time ago. I've used the
opportunity to update the text.

In previous times, when we had a "volatile" suite, that was kinda
opt-in.

Presently, a Debian stable installation is supposed to have, and has by
default, three suites enabled, which are separate only due to
technical and administrative reasons on the Debian side:
stable, stable-updates, and stable-security. They are not opt-in.

This would be bad. Indeed in the past we had situations where there
known bugs in the packages in `stable` which got immediately fixed
in `stable-updates`, but it was too late to put the fix into
`stable`.

You really want `stable-updates` to be enabled, also at image
building time.

No, they are not "nice to have".

Best,
Chris

Please point me to official documentation.

Me as an end user, wiki.debian.org looks to be legit official documentation.

If a few internal people in Debian community consider it different, what is public published should highlight clear the facts, the truth and not be kept private between a few people.

Is https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_archive_basics table 2.2 official documentation? It states OPTIONAL.

Should I interpret that optional is mandatory in Debian? It needs to be clearly explained in the documentation than.

PS. The iso installer (not the net-installer) which I use for offline and airgapped installs, it gives the result I stated of packages strict from the release.

If on some situations, there are problems after a release, and packages are pushed minutes after iso and cloud builds, I would expect an immediate correction and a release like 13.6.1 e planning the issues that break the 13.6 release.

Enviado desde mi iPhone

* Madalin Ignisca <hi@madalin.me> [260826 17:47]:

https://www.debian.org/releases/stable/release-notes/upgrading.en.html#adding-apt-internet-sources
is the official documentation for trixie.

No.

Obviously airgapped installations cannot use any http sources, and
d-i in this situation sets up the source it has (ISO).

You may expect a lot of things, maybe even your money back!
Debian works with the solutions it has, here "stable-updates".

Good luck,
Chris

An offline/airgapped installation will have access only to what's
available locally, e.g. the CD/DVD media.  That means it also won't have
access to the security repository, and the scenario you described in
your initial bug report applies equally to that repo as well.  There may
be packages installed on the cloud images that come from that repository
whose dependencies can only be fulfilled from that repository.
Presumably you have a local mirror, proxy, or other mechanism to inject
packages from stable-security into your airgapped environment.  I
recommend using the same approach for stable-updates.

In theory that's something that could happen, but (to my knowledge) it
never has (at least not in recent memory).  The stable-updates
repository is how we handle such scenarios.

noah

Please, can you explain to me what is https://www.debian.org/doc/manuals/debian-reference/

Is some documentation that somebody injected in Debian.org, to induce people in confusion?

So if something is published on Debian.org/* must be considered by end users as potentially some random text, full of false information?

I’m getting even more confused now. Sorry.

That document is official, but, to quote from it:

        Please treat this document as the secondary reference. This
        document does not replace any authoritative guides.

The release notes that Chris and I referenced earlier provide the
expected apt configuration for trixie, which enables stable-updates.
Please treat this as authoritative.

noah

Top header: Blog, Micronews, Planet, **Wiki**

Follow along the page, u have 2 things that are easy to understand: Download and User Support.

None of the pages point to OFFICIAL DOCUMENTATION.

So, the user considers, as common in almost all internet, that either is the Wiki, or the link to subpages that have visible included MANUAL in it.

Crawling all debian.org <http://debian.org/> website, there is nothing that would make somebody who is not being told directly by a Debian community member, that the RELEASE INFO is the official documentation.

And a note, the release information never explained what are each of the repositories listed there for a blind copy paste.

I’m very familiar with Debian, and with your explanation is clear to me: there is nothing for normal people to understand where is the official documentation. Information is very fragmented and opinionated on how things should work.

It would be wonderful if facts would be more clear about what is what and what is official.

Regards,
Madalin

You are providing me now a good advice to take the release notes as authoritative guide. OK. I understand that, but please than make the main pages of Debian to help everybody else to understand what is the source of truth, and what is something else that might contain false information but still is under the Debian.org/* domain.

PS: for end user, if all 3 are mandatory, it does not make sense to be separated. Probably should be redesigned to offer one single main channel to install and update a system.

The repository information in the Debian Reference is not false.  The
updates repository (and the security repository, for that matter!) is
optional, from a purely technical perspective.  That is, nothing in the
main repository depends on content from them.  Any package in the main
repository can be installed with all dependencies satisfied within that
repository.  This is why you're able to perform an offline installation
using only the DVD media.

Would it be helpful if the Debian Reference listed stable-updates as
"important", as it does for stable-security?  We can reassign this to
the debian-reference maintainer to make that change, if so.

Similarly, we can file a wishlist bug against (I believe) ftp.debian.org
to request this change.  However, for various reasons regarding the
process of updating and mirroring the various repositories, I would not
expect the change to be implemented any time soon.

noah