Re: on the nature of BROKEN

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

On Thu, Jun 20, 2024 at 09:08:17PM +0100, Jonathan Perkin wrote:
 >  * My major problem is with incorrect usage of ONLY_FOR_* or
 >    BROKEN_ON_*.  These are almost always wrong, almost always mask
 >    packages that could be legitimately available in binary package
 >    repositories, make it difficult for users to understand why a package
 >    is not available for their chosen repository, make it harder for
 >    people to work on fixes, don't support a reason message, and almost
 >    always end up bit-rotten as it puts the burden of noticing and
 >    changing them onto someone else.

I used to audit these periodically, and I admit I haven't done so in a
good while.

 > It may help to see where I'm coming from by imagining that it was
 > NetBSD-*-* that was being excluded everywhere for no other reason than it
 > wasn't tested during the commit, and you were the one having to go around
 > removing them to get packages you need building again.

That should definitely not be the way things happen. It sounds like we
have been misusing BROKEN_ON. (As well as using ONLY_FOR/NOT_FOR
incorrectly.)

I would need to go do an audit to get a sense of what the current
state is, and I don't think I'm going to have time for that anytime
soon.

My understanding is that the criteria used to be:

 - NOT_FOR/ONLY_FOR should be used only for things that do not even
make sense on the proposed target (e.g. macos gui libs on linux), or
things that would require a substantial porting effort (e.g.
retargeting a compiler).

 - BROKEN should only be used when either (a) even attempting to build
the package causes problems in the bulk build; or (b) a failure seen
in the bulk build reports has no realistic prospects of being fixed
and takes long enough to generate that doing so is a waste of
resources, as decided by the people building for that platform; or (c)
the package is so badly messed up that (unless someone comes along to
rescue it) we basically expect to remove it after another couple
quarters.

It sounds like people have been misusing it and you've been on the
receiving end.

Let's not do that...


(Also, I suspect that for case (b) it probably makes more sense to
maintain per-platform external exclusion lists than to go marking
packages.)

We could add reason messages. Seems potentially worthwhile...

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