Your message dated Wed, 26 Aug 2026 14:44:49 -0400
with message-id <[email protected]>
and subject line Re: Bug#1145659: cloud.debian.org: genericcloud image installs
stable-updates packages, making an opt-in suite effectively mandatory
has caused the Debian Bug report #1145659,
regarding cloud.debian.org: genericcloud image installs stable-updates
packages, making an opt-in suite effectively mandatory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1145659: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1145659
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cloud.debian.org
Severity: minor
User: [email protected]
Usertags: image
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
--- End Message ---
--- Begin Message ---
Control: severity -1 wishlist
Control: tags -1 + wontfix
On Wed, Aug 26, 2026 at 08:11:24PM +0200, Madalin Ignisca wrote:
> I start a fresh vm with Debian 13.6 cloud image, trusting it is built
> from release branch, not leaked after updates.
"leaked" is a strong word to use there.
> I disable the stable-updates, because I want less paper work (some
> audited companies must list every possible element of updates,
> disabling the stable-updates, and getting them every 2 months is more
> than perfect).
>
> I try to install next unbound, but can’t, it has a dependency on a
> python package, that has a dependency of another python package that
> is in unstable now, but I can’t because I limited to stable+security.
>
> Do you see the bug I try to express?
I do. As previously noted, though, this exact same problem can occur
with stable-security, yet you seem OK with installing packages from
there. Debian's position is that these are no different.
> And my proposal it can help everybody:
>
> Build the cloud release skipping stable-updates, only stable+security,
> and keep enabled the stable-updates in apt sources. So, the build gets
> 100% release, potentially with some security updated packages.
Again, stable-updates and stable-security are considered to be of the
same priority. We publish new images when any packages in any of the
default suites changes in such a way as to change the package set in the
images. A stability regression is no less severe then a security issue.
I have previously provided concrete examples of where this was
necessary.
> You understand the steps that can help all possible situations, and
> all system admins, mainly who work in environments with more audit on
> each change?
I fully understand that compliance requirements are tedious and time
consuming. I'm sorry you have to deal with this paperwork.
> I repeat, I do not suggest to permanently disable stable-updates. This
> must stay, as they were always with Debian. But to the release with
> that release lists, not a technically optional update.
We do not consider stable-updates to be optional. I'm sorry if this
does not match your expectation. Please note that images based on the
previously published stable point releases are available and will remain
so. You do not need to update to new images when we publish them. If
you want to avoid using images built with content from stable-updates,
you are free to continue using these images as long as they suit you.
noah
--- End Message ---
