On Tue, 26 Oct 2021 at 17:47:17 +0200, Mathias Behrle wrote:
> I have no say where this could be coded, but taking packages with lower
> versions from testing instead using the last available versions in unstable
> for
> an autopgktest running in unstable seems definitely not logical to me.
This isn't an autopkgtest running in unstable, though: it's an autopkgtest
running in testing, with only selected packages from unstable (hence /testing/
in the URL).
The reason it's taking certain packages from unstable is because the
testing migration scripts (britney) are trying to answer the question:
if I let various tryton modules (specifically the ones listed in
--pin-packages=unstable) migrate from unstable to testing, would
anything stop working? And the answer here seems to be: yes it would. So
ci.debian.net and autopkgtest are doing their job: they're alerting you
to a problem.
> Tryton 6.0 packages (in unstable) will generally break Tryton 5.0 (in
> testing).
> But all Tryton packages in unstable are 6.0 at the moment and depend on >=
> 6.0.
If Tryton 5 versions of tryton-modules-* are incompatible with Tryton 6,
that isn't currently reflected by their dependencies, so the testing
migration scripts have no way to know that the migration they're trying
to do here is considered wrong.
For example, tryton-modules-account (= 5.0.18-1) has:
Depends: tryton-server (>= 5.0)
apt (and therefore testing migration and autopkgtest) will consider
tryton-server 6.0.9-1 to be a valid solution to that dependency. If you
consider that to be *not* a valid solution, please set dependencies that
would forbid it.
There are three main strategies you could use to prevent a broken
partial upgrade:
1. versioned Depends, versioned Breaks:
tryton-modules-account (6.x) Depends: tryton-server (>= 6)
tryton-server (6.x) Breaks: tryton-modules-account (<< 6), etc.
2. Depends with a 2-ended range:
tryton-modules-account (6.x) Depends: tryton-server (>= 6),
tryton-server (<< 7)
3. Virtual package representing the overall API/ABI:
tryton-server (6.x) Provides: tryton-server-6
tryton-modules-account (6.x) Depends: tryton-server-6
Strategy 2 or 3 would probably be best in the long term, but you will
probably need some versioned Breaks (like strategy 1) during the
transition from the current situation to whichever strategy you choose.
Strategy 1 is appropriate if everything is "usually" compatible, with
infrequent incompatible changes that are hard to predict and need
an ad-hoc solution. For example, we use Depends/Breaks when a change
to gsettings-desktop-schemas requires closely-related packages like
gnome-control-center to be updated, which happens once every few years.
Strategies 2 and 3 are appropriate if the compatible/incompatible version
is easy to predict in advance. For example, we use Depends with a range
for GNOME Shell extensions like gnome-shell-extension-caffeine (each
GNOME Shell extension is only compatible with a limited range of GNOME
Shell versions), and we use a virtual package representing the overall
API for Apache modules.
smcv
