Rust packaging makes heavy use of versioned virtual packages to allow
multiple versions of a crate to coexist if needed (though this functionality
is only occasionally actually used).

Britney now seems to understand versioned virtual packages (at least in simple
cases) for the main migration and for auto removals, but it still does not
seem to properly understand them for testing migration.

For example at the time of writing this bug report (though probablly not for
long afterwards as I intend to upload a workaround) this can be seen with
rust-datetime and rust-zoneinfo-compiled.

librust-zoneinfo-compiled-dev 0.4.8-1 in bookworm depends on
librust-datetime-0.4+default-dev (>= 0.4.7-~~) which is provided by
librust-datetime-dev 0.4.7-2

librust-zoneinfo-compiled-dev 0.5.1-2 in sid depends on
librust-datetime-0.5-dev (>= 0.5.2-~~) which is provided by
librust-datetime-dev 0.5.2-3

rust-datetime shows

While rust-zoneinfo-compiled shows

We see that when it comes to excuses britney understands that these packages
need to go in togehter, rust-datetime is shown as having an implicit dependency
on rust-zoneinfo-compiled and rust-zoneinfo-compiled is shown as having
a dependency and build-dependency on rust-datetime.

However when it comes to the autopkgtest britney is refusing to migrate
rust-datetime based on an autopkgtest of the old rust-datetime. When
we look at the log we see the regular dependency installation fails

It then goes into the fallback dependency installation, this succeeds but it
installs the version of librust-zoneinfo-compiled-dev from sid. Autopkgtest
then tries to run the tests from testings rust-zoneinfo-compiled against
the librust-zoneinfo-compiled-dev from sid which fails with a crate directory
not found error.

I belive this has been worked around in newer versions of debcargo by marking
the tests as skip if uninstallable which prevents autopkgtest from heading
down the fallback dependency solving rabbit hole, but it still seems less than
ideal for britney to be behaving like this and we still have packages created
with older versions of debcargo in the archive.

for scheduling/selecting autopkgtests".

Hi Peter,

I now have a script that can take a snapshot of (hopefully) all the
things I need to create a test case for the britney2 test suite. Can you
warn me again when a similar case happens? I have some hope that it got
improved by some of my recent changes. It would also be good to know if
you haven't seen this in a while.

Paul

I can try.

Just how recent were these changes? If they were very recent I may not
have had enough time to notice them.

The situation over the last year or two seems to be that the autopkgtest
scheduler has some understanding of versioned provides, but only *after*
all builds are complete, if builds are missing the changes in versioned
provides are ignored.

This often results in britney scheduling a "stupid" autopkgtest initially,
then following up with a "sensible" one when it retrys after slow
architectures catch up.

There are also problems in more complex scenarios. Based on my
obvervarions of britney's behaviour and the assumption that the
first package in the "trigger" list is the one that actually triggered
the test.

the simplest scenario which I'm pretty sure fails (or at least failed
as-of a few weeks ago) is where you have packages like.

* A depends on B through a versioned provides
* A depends on C through a versioned provides
* B depends on C through a versioned provides

C removes a versioned provides and adds a new one (usually
as a result of a rust semver bump). A and B are adapted to the
new version of C but A's dependency on B
remains unchanged.

Once all the builds are in A and C will trigger
autopkgtests of A with the new versions of A and C
but not the new version of B. This will likely trigger the
fallback depsolver in debci but will generally pass.

B on the other hand will trigger the autopkgtest of A
with only the new version of B. This will trigger the
fallback depsolver and cause a package/test mismatch. The
package/test mismatch in turn will often  lead to a "crate
directory not fonud" error.

A more subtle variant.of this comes if A bumps it's
dependecy on B as part of the update. In this case the
autopkgtest of A triggered by A correctly includes all
three packages and passes. but the autopkgtests of A
triggered by B and C are still "wrong". If no follow up
updates are needed this doesn't matter, the autopkgtest
triggered by A overrides but if follow-up uploads are
needed this can become a problem.

Hi,


I didn't have specifics in mind, just some of my work since you filed
the bug.


Right.


I created a test case in the test suite for this [1].


Yes, currently it does, but it *also* triggers tests from A, B and C
with all three packages from unstable (triggered by C).


Also this test case (in the variants directory) doesn't work as you
describe.

Can you please check the test cases (the Packages_i386 and Sources files
in var/data/(unstable|testing) and try to find where I didn't understand
you correctly?

Paul

[1] https://salsa.debian.org/debian/britney2-tests/-/commit/29d8220

Hi Peter,


Prompted by Matthias on IRC and the situation with rust-glib-sys I
looked into this again yesterday. After several hours I was able to spot
the thing that made britney2 schedule the wrong tests on loong64.
Initially I thought that was because we added loong64 testing rather
late. So I was trying variants of the scenarios already mentioned in
this bug, but all worked (not ideally, but getting the job done). The
reason why on loong64 britney2 gets the wrong set is because of
BREAK_ARCHES. I have a local testcase for that now and will shape it
ready for upload. I think that fixing the AutopkgtestPolicy for the
current BREAK_ARCHES logic (in DependsPolicy) is going to be non-trivial
work, I don't expect that to be fixed soon.

My conclusion of this exercise is that I still can't reproduce the issue
that was reported originally. Apart from the loong64 situation now,
please notify me immediately if you spot a situation where britney2
doesn't schedule at least one good combination, such that I can take a
snapshot for debugging. Given a remark on IRC related to suricata [1], I
wonder if *that* case is what you're running into occasionally. I have a
snapshot [2] for that case and will hopefully look into that to figure
out what's wrong there.

Paul

[1] suricata depends on librte-common-mlx5-26, librte-common-mlx5-26 is
pulled from unstable, librte-common-mlx5-26 depends on ibverbs-providers
(>= 63) which is in unstable, but ibverbs-providers is pulled in the job
from testing
[2]
respighi:/home/elbrus/tmp/live-2026-06-04_bug-1138829_smarter-easy-hints.tar.xz

It may be too late since I uploaded a workaround before seeing this mail, and it may not be exactly what you are looking for but one example of trouble that popped up recently was glycin.

This is a case where figuring out that migrating all of the packages from the new glycin source breaks the dependencies of rust-libglycin-gtk4-rebind and rust-libglycin-gtk4-rebind-sys requires going down and back up the dependency graph, taking account of virtual packages in both directions.

I don't think I've seen the "stupid test before all arches are built good test afterwards" one for a while. So perhaps that one is fixed, or perhaps I just haven't noticed it.