Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
Like #1064428, copying things here that we discussed on IRC... Sorry if I was unclear. The title is indeed incorrect if the binary takeover is arch:all. I think the behavior is alright. If that's true, it should probably be tested for, because it might be unexpected and broken by future changes. To reiterate what happens now: If a binNMU occurs on a source, but a different source is taking over one or more of the binaries from the binNMU'd source: * If the taking-over source is okayed to migrate, the takeover occurs. The binNMU is blocked due to "newerintesting". * If the taking-over source is not okay to migrate... - If all of the binaries being taken over are arch-independent, the binNMU is allowed to migrate. (the arch-indep binaries are not changed on a binNMU, but even if they were in a hypothentical situation, I don't believe this behavior would change) - If any binary being taken over is arch-dependent, britney declares the binary from the taking-over source "cruft" in the taken-over source's verdict. If cruft is allowed, the binNMU migrates. If cruft is not allowed, the binNMU is blocked. I hope this helps. Thanks for taking a look!
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
/me is drinking coffee now *and* looking at test bug-709460 On 29-02-2024 8:43 a.m., Paul Gevers wrote: but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. From you bug report title I was expecting that britney2 currently *didn't* migrate the binNMU's of src:pkga (or in the test case llvm-3.2-arch). However, ignoring arch:all binaries actually achieves that binaries from src:pkga are *eligible* for migration *despite* some of their (wrongly assigned) arch:all binaries should not. I think that's the behavior that we want (unless the failure to support arch:all binNMU's in the infrastructure is solely caused by this implementation detail in britney2). Did you interpret the final result of bug-709460 wrong or do I not understand what you tried to tell us? So, rethinking and if I understand correctly, this bug is about arch:any takeovers, whereas bug 709460 was about arch:all takeovers: src:pkga is newer in source-suite than in target-suite src:pkga builds bin:takeover arch:$any src:pkga has been binNMU-ed src:pkgb is in source-suite only src:pkgb builds bin:takeover arch:$any (higher version than from src:pkga) Yes, ideally the binNMU of src:pkga migrates, but I'm not sure it's worth the effort. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
grr, sent too soon (do I need coffee?) On 29-02-2024 8:33 a.m., Paul Gevers wrote: Hi, On 21-02-2024 10:53 p.m., Dalton Durst wrote: This condition only occurs when both source packages are considerable for migration. If both source packages provide both binaries, pkgb is found to supersede pkga, so pkga is not considered for migration. If pkgb passes all policy, it will migrate and pkga will probably be forgotten about (even though it considers pkgb its own cruft). This may be expected behavior, Expected behavior in the sense that once src:pkgb migrates, it's OK to forget about bin:takeover from src:pkga. I think *ideally* britney2 would migrate the binNMU from src:pkga while src:pkgb is blocked, but I think it's a niche case that is acceptable to not support. What would be bad is if bin:takeover from src:pkgb migrates without src:pkgb (bug 709460). > but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. Which means that, if we fix bug 1064428 with your proposal to just skip the check, we need to add other code to prevent reintroduction of bug 709460. Either properly migrating bin:takeover from src:pkga, or by blocking bin:takeover altogether (this bug). Depending on required complexity [1], I don't think it's bad if we would end up wontfix-ing this bug (#1064427) I forgot it's important here to reason about arch:all vs arch:$any. In case bin:takeover is arch:all there will not be an binNMU of it, so there's no version of it that needs to migrate as long as src:pkgb is blocked. [1] I haven't inspected the code yet, but keeping track of all binary versions and reason about them instead of just taking the highest version seems like a large paradigm shift in britney2 (but I could be wrong). This still holds though. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
Hi, On 21-02-2024 10:53 p.m., Dalton Durst wrote: This condition only occurs when both source packages are considerable for migration. If both source packages provide both binaries, pkgb is found to supersede pkga, so pkga is not considered for migration. If pkgb passes all policy, it will migrate and pkga will probably be forgotten about (even though it considers pkgb its own cruft). This may be expected behavior, Expected behavior in the sense that once src:pkgb migrates, it's OK to forget about bin:takeover from src:pkga. I think *ideally* britney2 would migrate the binNMU from src:pkga while src:pkgb is blocked, but I think it's a niche case that is acceptable to not support. What would be bad is if bin:takeover from src:pkgb migrates without src:pkgb (bug 709460). but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. Which means that, if we fix bug 1064428 with your proposal to just skip the check, we need to add other code to prevent reintroduction of bug 709460. Either properly migrating bin:takeover from src:pkga, or by blocking bin:takeover altogether (this bug). Depending on required complexity [1], I don't think it's bad if we would end up wontfix-ing this bug (#1064427) Paul [1] I haven't inspected the code yet, but keeping track of all binary versions and reason about them instead of just taking the highest version seems like a large paradigm shift in britney2 (but I could be wrong). OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress
Package: release.debian.org Severity: normal Usertags: britney Consider the following situation: * pkga produces takeover and pkga1 - it is already in testing * pkgb is taking over takeover and also produces pkgb1 - it is not a candidate for migration because it is missing a build on i386 (that architecture still has old binaries from this source) * pkga has been binNMU'd When this occurs, britney correctly declares pkgb unfit for migration. However, it also declares pkga unfit for migration because pkgb's 'takeover' binary is considered pkga's cruft. This condition only occurs when both source packages are considerable for migration. If both source packages provide both binaries, pkgb is found to supersede pkga, so pkga is not considered for migration. If pkgb passes all policy, it will migrate and pkga will probably be forgotten about (even though it considers pkgb its own cruft). This may be expected behavior, but I exposed it in the bug-709460 test case while trying to enable britney to check architecture-independent packages. Currently the behavior is masked in that case because britney skips the -doc package due to it being arch-indep. If this _is_ expected behavior, bug-709460 is currently passing erroneously. I've attached a patch to the britney2-tests repository adding a test which demonstrates this situation. If britney2 is working as expected, then bug-709460 may need to be changed so it does not cause this situation. If not, what change is needed in britney? Thanks, Dalton 0001-WIP-Test-for-binNMU-occurring-during-a-halted-partia.patch Description: Binary data
