--no-strict-pinning should enable you to install those older non-candidate versions, I can't say why it doesn't work for you; you could dump the solver request without it by adding: -o Dir::Log::Solver=/path/to/a/file and send it and then maybe its possible to reproduce this locally, but of course this may leak data. There is one bug in the backtracking potentially where it gives up too early, though it's not clear to me it's currently reachable.
I have create a repository that recreates the issue. You can find it here:
https://github.com/robojan/exp_apt_repo
The log.txt contains the solver request. This contains a devcontainer where I build apt from source. I have a few packages in the repository the simulate the scenario.
If i then try to install it I get the dependency error. I hope this helps you find the issue.
So my question is. Can APT handle dependencies in this way? If so, what are we doing wrong? if not, how should we solve this problem. I would not like to implement a dependency solver on top of apt.The normal way to do this is to include the version in the package, that is, a-1.0, b-1.0, then a-1.0 Depends b-1.0. You could have them all Provides: a (= 1.0) and so on, and then use those for Depends: a (= 1.0), this might even work if you also add a real package a that Depends: a-2.0 (like the latest version), or any of the versions of a, that is, a-2.0 | a-1.0. This may be useful for convenience. I mean the question ultimately is what you want to do, there isn't much point in shipping a (= 1) and a (= 2) in the same repository, you can't ship a bug fix to the a (= 1) version, and upgrades will always install the a (= 2) one.
We have multiple projects, these project may use the same packages, but one project may decide to keep the version of a package on an older version, while another package is up-to-date. These packages can have common dependencies. This is where the problem arises. For normal development everyone should use the latest version. So we would like to have one repository with all versions, so that the projects are free to freeze a package at will.
Thanks,
Robbert-Jan