Hi Paul, Thanks very much for your reply.
For what it's worth, I don't necessarily need britney2 to handle these migrations "correctly", and I don't think Debian does either. However, there is some behavior instability when arch-indep and arch-dep packages are proposed in different ways in the same source. It would be okay if britney2 simply threw the migration out with the message "this is too complicated, some human should tell the archive what to do." Instead, it either passes the arch-indep package through as a rider on another change or seems to ignore the package entirely. On Wed, Feb 21, 2024, at 11:59 PM, Paul Gevers wrote: > On 21-02-2024 23:50, Dalton Durst wrote: > > > If the > > package were binNMU'd, though, britney would migrate everything > > including the arch:all package if it passed checks. > > In Debian, binNMU-ing a arch:all package is known to not work. I don't > know if this bug is the reason why it doesn't work, but I've been taught > this when I joined the Release Team. I think I tried once by accident > (or ignorance) and the binNMU didn't work. Sorry, I might not have been as clear as possible here. The problem is that the arch:all packages won't migrate unless there's another valid migration item in the source. So an arch:all package could be stuck in unstable for a while without moving. As soon as a valid binNMU appears (without replacing the arch:all package, as is policy), the arch:all package might migrate too. > > This behavior > > instability might be undesirable. > > But there _might_ be more infrastructure problems than britney2. Agreed. In fact, I found even spookier behavior in britney2 while adding more tests. To explain: when this odd situation occurs, the arch:all package seems to be checked for validity, at least a little. If it is installable, it migrates with the binNMU. If it is not installable, it does not migrate with the binNMU. This seems like a good thing, britney2 is somehow avoiding a non-installable package in testing. However, in all cases, the excuses output does not accurately reflect the decisions that were made during britney's run. Depending on how the downstream software actually performs migration, you could still get different results from the same britney run. When the arch:all package is "accepted" (scare quotes because britney2 says the package is ignored in excuses), it appears in HeidiResult but not HeidiResultDelta. This is a little hard to explain, so I've attached another three tests which demonstrate the situation. "arch-all-migrates-with-broken" demonstrates what happens when the arch:all package itself is not installable, but the binNMU is. "arch-all-migrates-with-others" shows an OK arch:all and arch:any migration (with the :all package appearing in HeidiResult but not the delta). "arch-all-migrates-without-others" shows what happens "at rest," when all arch-dep binaries for the source are already in testing. "...without-others" should be a repeat of the test attached in my first message, but they can all be run with "bin/runtests ../britney2/britney.py t test-out /arch-all-migrates.*/" which is nice. > > > The code which skips arch:all packages dates all the way back to > > britney2's original import[1], so it's not clear if it's still > > load-bearing. > > In the old days, an arch:all package was never build on a buildd, but > uploaded by the uploader (together with the source). It's very possible > that that fact is related to the original intent. Makes sense. > I am currently working an a change to britney2 that (based on > Package-List entries in the Sources) will prevent migration of sources > which build arch:all binaries. That will also work around bug #915948 > (in dak) and fix bug #887060 (in britney2 for Sources build from > source.changes files). From our conversation on IRC I take it that that > wouldn't solve *your* case as you're using aptly and apparently that > builds the Sources (with or without a Package-List) from what's in the > archive so it would still run into this issue. That sounds like a really good addition. I suppose it would mark a change in my situation because the unstable source package's Package-List would be different from the testing package. Maybe that change would be enough to get some output from britney2 when this odd situation is hit? Thanks again, Dalton
0001-WIP-Add-tests-for-new-arch-all-binaries.patch
Description: Binary data
