Re: packages expected to fail on some archs

[Guillem Jover <guillem@debian.org>]

Hi!

[ Mostly to summarize the status re dpkg. ]

On Sun, 2022-09-11 at 17:08:57 +0200, Samuel Thibault wrote:
> The issue we see is that some DDs end up setting a hardcoded list in
> the "Architecture" field, rather than just letting builds keep failing
> on these archs (and then possibly succeeding after some time whenever
> somebody contributes a fix upstream that gets propagated to Debian).

> That said, I guess DDs would still set a manual Arch list so as to get
> the red flags away from their sight on the buildd page status, e.g. from
> https://buildd.debian.org/status/package.php?p=sthibault%40debian.org&comaint=yes&compact=compact
> so that they can easily notice which build failures are actually not
> expected, to be able to efficiently work on those.
> 
> So perhaps what is missing is a way to express that an FTBFS is
> expected, so that the buildd page status represents it differently, e.g.
> in orange rather than red?  The idea would be that it should be really
> easy to set (as easy as setting an Architecture list) so that we can
> easily recommend it.

Yes, I agree that this seems like a problem with representing state,
where people feel the need to move from the red to green. I think the
proposals that have been mentioned elsethread are nice, where a
regression would be red but whenever a package was not previously
built (because it never has or it got removed) for an arch, that
is shown in a way consistent with how testing transitions would take
it (orange or another non-red color seems good).

Something else to consider is that, for packages that make sense
porting, deny-listing them from building means we do not have build
failure logs, so deciding what to port or trying to check for patterns
becomes more costly for humans, of course at the cost of potentially
throwing at it buildd resources.

> We could for instance:
> - Add an Architecture-FTBFS field to debian/control
> - Add an environment variable to debian/rules so that on these archs dh
>   fails with a different exit code that buildds would notice.
> - Add a Architecture-FTBFS field in the wb database that DDs can set
> 
> The tricky part I see is that AIUI the buildd status page doesn't
> have direct access to debian/control, only to the wb database, so the
> first solution is not immediate to implement. The third option would
> be the most obvious from the buildd point of view, but that's not very
> convenient for DDs. Possibly such field could be automatically set
> according to the Packages entry when a newer upload is done?

While these might be worth it on their own, it feels (as has been
covered elsethread) to be a bit of a workaround for lack of better
expressiveness in our Architecture declarations, and build state
representation. But see my reply to #807263 about how I see the
different cases. Also for the third we already had something similar
with the Packages-arch-specific file, but my understanding is that we
are moving away from it?

The common mentioned omissions are:

  * Lack of negated architectures in the field. As mentioned on #807264
    this is kind of supported already by dpkg, but it would need to be
    accepted by the project, and the actual syntax and semantics
    documented. (Personally I think this should not generally be used,
    and there are very few cases where this seems legitimate?)

  * Lack of bits/endianness arch "aliases" (#962848). The main problem
    with this one is that we cannot simply add such aliases, as then
    those would silently be considered as regular arches, and they do
    not map into the current naming convention at all. These would need
    to be added with a breaking syntax (say with some non-accepted
    char, such as % or whatever) so that they do not introduce silent
    breakage. This would then need to be supported by anything
    handling arch restrictions (field and dependencies) which can be a
    rather large surface. Then there is the problem that architectures
    are evaluated as ORed lists, and the bits/endianness might require
    to be treated as ANDed lists some times (of course the latter
    could be handled by combining them into single aliases, but meh).

Thanks,
Guillem