Trixie suite regularly with conflicting package versions/dependencies

[MichaIng]

Hey guys,

we start testing and building for Debian testing pretty early, basically once it is forked off as new testing version. What happens every few weeks is that the sync with Debian testing is somehow incomplete or done at a bad time, so that some packages have a newer version and dependencies for other packages which are not available yet.

Current example is liblocale-gettext-perl v1.07-6+b1 which depends on perl-base >=5.38.2-3, but the perl-base package provided is still at v5.36.0-10. liblocale-gettext-perl has priority "required" and perl-base "essential", hence both are pretty much mandatory or forcefully installed by APT. A conflict between them makes setting up a Raspbian Trixie system currently impossible without hacks.

I know the testing suite has no priority, but probably there is some easy solution? I observe this since years, as well when Buster, Bullseye and Bookworm were testing, I guess syncing versions/sources with Debian is a longer process during which changes can happen in Debian's volatile testing repo. Not sure whether an internal consistency test is suitable, or whether there are time frames during which changes in Debian can be ruled out. I never observed such problems with Raspbian's stable suite, so probably some mechanism is applied there, which could be applied to testing as well?

Best regards,

Micha

[peter green (plugwash)]

Raspbian is a rebuild, so after stuff is imported from Debian it must be built. Similarly when transitions happen we must rebuild the effected packages.

We have a "migrator" script which is supposed to keep the worst breakage out of the main testing suite but it's far from perfect. A "better" script could keep more breakage out but would also likely make it harder to troubleshoot why things are not migrating (I rejected Debian's "britney" because it's output is unusablly crap)

The reason you see a lot less of this in the stable suites is simply that there is far less chur

[MichaIng (michaing)]

Theoretically, after the import, looping through really all packages and checking whether their declared dependencies (non-recursively) are present, should work, but is probably a time consuming process. If a dependency is not available, Debian testing could be checked for its current dependant and dependency versions, as one of the two must be out of sync.

Another approach: Maybe it is possible to define some cool-down time after source imports, during which no other change at the Debian testing repo must occur, before builds are started, or otherwise these follow-up changes are imported as well first. This could lower the risk that builds are done at an inconsistent/conflicting repo state. But probably changes happen much more regular than I recognise them with the limited number of packages on my Debian systems.

And a last idea: Syncing with a Debian snapshot, instead of the live repo: https://snapshot.debian.org/archive/debian/20240201T093520Z/
I assume those to be always consistent, and the latest is not more than one day old.

But I am just thinking around with lack of insights, obviously :).

[MichaIng (michaing)]

Something similar happened now on Bookworm/stable:
The current Bookworm Packages.xz contains:

Package: ca-certificates-java
Version: 20230710~deb12u1
Installed-Size: 43
Maintainer: Debian Java Maintainers <email address hidden>
Architecture: all
Depends: ca-certificates (>= 20210120)
Breaks: ..., openjdk-8-jre-headless (<< 8u382~b04-2~)
...

Package: openjdk-8-jre-headless
Source: openjdk-8
Version: 8u312-b07-1+rpi1

Hence OpenJDK 8 cannot be installed because the ca-certificates-java package it depends on breaks on OpenJDK 8 versions which include the one shipped by the repo.

I know you added OpenJDK 8 to Raspbian packages manually, as newer OpenJDK versions (with HotSpot JVM) do not run on ARMv6. Debian does not ship it anymore since Stretch, but their ca-certificates-java package still contains the "breaks" on openjdk-8-jre-headless versions older than what was shipped by Sid/unstable at build time: https://packages.debian.org/sid/openjdk-8-jre-headless

This means that, whenever a new version of ca-certificates-java is pulled from Debian sources, openjdk-8 must be updated as well, to avoid such possible breakage.

Sadly it is not really possible to add the same "simple" check for "breaks" and "conflicts" like I suggested for dependencies above, since it is totally normal that there are conflicting packages in Debian. But theoretically, the dependency check could not only check whether the required dependency exists, but also whether this has "breaks" on the dependant package version. But seems pretty much overkill for this very specific case. Updating openjdk-8 always together with ca-certificates-java should do.

[MichaIng (michaing)]

And now gcc-14-base is missing while everything else from the gcc-14 source is present (and depends on gcc-14-base, of course). I'll stop spamming further examples.

I think the idea to pull sources always form the latest Debian snapshot (snapshot.debian.org), instead of live repo, is a pretty simple and solid solution, making all post processing of the migrator script obsolete, assuring the any Raspbian suite is always perfectly consistent. And given that Raspbian is usually a few days behind Debian, regarding some packages at least, it is no significant regression that it will be up to a day more (as Debian snapshots are generated daily).