Re: on the nature of BROKEN

[Jonathan Perkin <jperkin%mnx.io@localhost>]

> If I'm confused, and there are multiple kinds of BROKEN, such that
> category 2 people think some that should cause package builds to be
> skipped in bulk builds and some should run and fail, please explain.

Briefly (I'm away for the weekend so won't have many cycles for the next 
few hours):

 * I don't mind BROKEN itself too much.  Given it specifically requires
   a custom message to indicate the problem, and will be missing for
   everyone, it's generally used in the right way to indicate that,
   essentially, the package should be moved to wip because it's
   currently effectively useless with no hope of a build being
   successful.  There's no need for an IGNORE_BROKEN in these cases.

 * 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'm not hugely keen on IGNORE_BROKEN.  I fear it would give people more 
of an excuse to add yet more exclusions without thinking through what 
problem they are actually trying to solve.  I just want to see 
legitimate usage of the variables that we already have, where we only 
exclude platforms where it is logically impossible for the package to 
build on them.

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.

--
Jonathan Perkin   -   mnx.io   -   pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com