Re: on the nature of BROKEN

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Thu, Jun 20, 2024 at 02:01:35PM -0400, Greg Troxel wrote:
 > I know there are two schools of thought:
 > 
 >   1) If we know a package won't build (because of something that is a bug,
 >   including 'ought to be more portable but isn't), set BROKEN or
 >   BROKEN_ON to
 > 
 >     a) clue in the human trying to build right away
 > 
 >     b) avoid wasting cycles in bulk
 > 
 >   2) Don't set BROKEN because it masks failures and it's useful to see
 >   them in bulk reports.
 > 
 > Broadly I think 1 is what's in the guide and maintstream doctrine and 2
 > is jperkin's view.
 > 
 > I am somewhat sympathetic to 2 but not nearly enough to throw 1
 > overboard, and we as a group not all doing the same thing isn't good.

First, recall that we have both BROKEN and NOT_FOR. The idea, when
these were deployed as parallel fully general mechanisms, was that
packages marked BROKEN should be reported as broken in bulk build
reports, and packages marked NOT_FOR should be skipped silently.
AFAIK, this distinction has still not been implemented in pbulk, O(10)
years later. Maybe if we got this working as intended, there would be
less pressure.

However, it sounds like you're talking about something else, which is
the difference between including

   Package skynet-plugins 1.2.6 is marked BROKEN on arm64:
     Includes extensive x86 assembly.

and including the actual build failure.

It's definitely nice to have the latter, especially for packages that
are broken on particular platforms that most people don't have access
to. E.g. if someone marks a package BROKEN on m68k, chances are nobody
will ever investigate further, whereas lots of build failures can get
patched up semi-blind just by looking at the failure output.

 > So, I wonder if we should have an IGNORE_BROKEN that people doing bulk
 > builds can set, to get the kind of results they want, while the people
 > that want the guide-described semantics get those.  Then there would be
 > no conflict, and we can have the best of both worlds.

However, I don't think this is going to help all that much, because
the question of whether to go ahead and produce the errors is likely
more nuanced than an on-off switch. For example, if I were running
m68k builds, and say firefox was known to not build, I'd likely not
want to ever attempt it because of the size and the odds of anyone
doing anything useful with the result. That's quite different from,
say, vim.

Also, we often use BROKEN for cases where we specifically don't want
to even attempt a build, such as packages that hang, and these would
need to be marked BROKEN_HARDER or something and that's a losing
proposition.

-- 
David A. Holland
dholland%netbsd.org@localhost