* Paul Gevers: " Re: Bug#997865: autopkgtest: dependency satisfied from testing instead of unstable" (Tue, 26 Oct 2021 14:01:24 +0200):
Hi Paul, big thanks for your quick reaction. > On 26-10-2021 11:25, Mathias Behrle wrote: > > I am setting the severity to important because this behavior blocks > > the migration of the Tryton suite to testing. Testing has Tryton 5.0, > > Unstable has Tryton 6.0. > > > > The problem can be seen at > > https://ci.debian.net/data/autopkgtest/testing/amd64/t/tryton-modules-account-payment/16194968/log.gz > > > > Setting up tryton-modules-currency (6.0.1-1) ... > > Setting up tryton-modules-country (6.0.1-1) ... > > Setting up tryton-modules-party (6.0.2-1) ... > > Setting up tryton-modules-company (6.0.5-1) ... > > Setting up tryton-modules-account (6.0.3-1) ... > > Setting up tryton-modules-product (5.0.5-1) ... > > Setting up tryton-modules-account-product (5.0.5-1) ... > > Setting up tryton-modules-account-invoice (5.0.14-1) ... > > Setting up tryton-modules-account-payment (6.0.1-1) ... > > Setting up autopkgtest-satdep (0) ... > > > > The versioned depends of tryton-modules-account-payment are pulled in > > correctly, while the depends of the tests/control is (partly!) satisfied > > from testing instead of unstable. The relevant control file is [1]. > > And why do you think that is wrong? britney (the migration software run > the Release Team (of which I am a member)) tries to test with as much as > possible from testing as allowed by version constraints. So, if there's > nothing *forcing* the versions from unstable, than we try to use the > versions from testing. The log you pointed at has this: > --pin-packages=unstable=src:tryton-modules-account-payment,src:tryton-modules-account,src:tryton-modules-company,src:tryton-modules-country,src:tryton-modules-currency,src:tryton-modules-party,src:tryton-proteus,src:tryton-server It is very interesting that tryton-proteus is part of this pinning despite it doesn't appear at all in debian/control, but only in debian/tests/control. S. https://salsa.debian.org/tryton-team/tryton-modules-account-payment/-/blob/debian/debian/tests/control > That means that britney considered all those packages to be needed from > unstable, but nothing more and autopktest will request apt to install > only that set from unstable. As we see no "fallback" apparently that's > possible with current version constraints. > > > tryton-proteus is correctly pulled in as > > Setting up tryton-proteus (6.0.3-1) > > Because of the versioned Depends: > https://packages.debian.org/unstable/tryton-modules-account-payment tryton-proteus is *not* part of the versioned depends in debian/control. S. https://salsa.debian.org/tryton-team/tryton-modules-account-payment/-/blob/debian/debian/control > > while tryton-modules-account-invoice is falsely taken from testing > > Setting up tryton-modules-account-invoice (5.0.14-1) ... > > But where is it coded that that version is wrong? 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. Besides the fact that the choice seems to happen randomly, see above. > > The test run was on 25 Oct 2021, tryton-modules-account-invoice 6.0.3-1 was > > accepted into unstable at 19 Oct 2021. > > > > Please advise, if this is not the correct package or if something else > > is missing. > > If at all, the issue lies with britney, but as far as I see it, the > tryton stack is probably missing a versioned (test) dependency or > versioned Breaks somewhere. As I have no clue about the tryton stack, I > can only advice in general terms. Please consider if one of the packages > in unstable now breaks a package in testing that is allowed to be > combined by the current versions. 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 *only* the test is broken, For me only tests are broken. BTW piuparts shows no problems with the Tryton packages. > you can either 1) add the Breaks nevertheless (not all people are fan of > this), That means I would have to add Breaks against all *test* dependencies < 6.0? Sounds quite odd. > 2) add a *versioned* *test* Dependency in the "broken" package or Of course I would favor that solution, *if* it would be injectable like dh_gencontrol -- -Vversion:major="$(MAJOR)" but that's unfortunately not the case. I would have to go with hard coded versions in tests/control which is from maintainer point of view a PITA. > 3) ask the Release Team (me) to manually trigger the combination. Note > that the first two give you control, while the latter means work for me. Of course the latter should and will be the last ressort. > You'd need to explain why it's only the test that's broken and I prefer > you handle it with one of the options in your control. Before considering further steps please advise once more on the astonishing behavior with package pinning. Why is tryton-proteus pulled in with the desired version from unstable, but tryton-modules-account-invoice is not? Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
