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
