Hi Feri, Please CC me on reply. >> I think I understand the rest, although I don't know whether the >> autopkgtest regression blocks migration indefinitely. That would be >> unfortunate, because unstable pcs needs unstable pacemaker, so they >> deadlock... > > I think you will need to ask the release team to hint them in > together. Yes, they will block unless overridden by the release team, or better, when you change your package relations such that the migration software figures out that they need to be tested together. (The release team and I can do the latter manually, but that is not really sustainable.) With the current code your options are: - *versioned* depends on one of the binary packages from the source you want from unstable in any of the binary packages that is going to be taken from unstable already - *versioned* breaks or conflicts on the binary packages from the source you want from unstable in any of the binary packages that is going to be taken from unstable - *versioned* test dependency in the package that is used for autopkgtest (only helps if the version that is tested is already taken from unstable). The version of the test dependency will NOT be added to the triggers, but if the version of the autopktest is going to be taken from unstable already due to other considerations, with the current settings of ci.d.n and autopkgtest the required version will be installed. Mind you, if the migration software asks for a test with multiple packages from unstable (visible in the triggers string) a PASS will be used for all those packages, so you only need to "fix" this in one package. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature