Re: CVS commit: pkgsrc/games/eureka

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2020-05-15 at 17:19 BST, Michael Bäuerle wrote:

> I have added it after reading this section of the documentation:
> | 
> | 21.1.7. Packages that cannot or should not be built
> | 
> | There are several reasons why a package might be instructed to not build
> | under certain circumstances. If the package builds and runs on most
> | platforms, the exceptions should be noted with BROKEN_ON_PLATFORM. [...]
> 
> Maybe this section should list the reasons, when BROKEN_ON_PLATFORM should
> be used (or not).

Yeh, I don't really like how that section is worded, and it's
understandable that it might cause confusion.

{NOT,ONLY}_FOR_PLATFORM are very simple, they're to be used when a
package fundamentally cannot function on the target.  For example,
emulators/compat80 on Cygwin, or misc/libreoffice6-bin on VAX.

BROKEN is a bit more nuanced.  A good example of it being used would
be the recent addition of BROKEN="Fails to build with OpenSSL 1.1" to
various packages.  It's clear, understood by all, and saves time in
bulk builds where we know the package cannot be built until major work
has been done to fix it.

Unless there is a specific reason that the package should not be built
though, it should be avoided.  It's just hiding bugs that should be
fixed instead (see chat/icbirc for a particularly bad example of
this), and removes useful information from bulk build reports.

My list of valid reasons for adding BROKEN_* would be something like:

 * A package cannot fundamentally be built with the current state of
   pkgsrc (e.g. the openssl 1.1 stuff) and will likely be removed from
   the tree in the near future unless fixed.

 * A package cannot be built for certain platforms, but there is no
   fundamental reason why this can't change nor why the package should
   be removed.  A good example here would be the various
   BROKEN_ON_PLATFORM=${LP64PLATFORMS} for software that is not 64-bit
   clean (rare these days!) yet works fine otherwise.

 * Some options have been selected that make the package unbuildable.

Reasons that might sometimes make sense, but where a judgement call
needs to be made would be:

 * A package builds but does not function correctly.  You could argue
   this both ways - it's not great shipping software that we know will
   not work, e.g. it crashes on some platforms, but by marking it
   BROKEN we make it a lot harder for people to start debugging and
   fixing the problem because now they have to go and build it
   themselves.  It's also possible the bug might have been fixed ages
   ago (is comms/asterisk* really still broken on i386 for example or
   are we just cargo-culting around undocumented issues?).

Reasons that it should not be used would be:

 * The package has build errors.  These should be exposed so that
   people are given the opportunity to fix them.

Hope that helps.  I'm sure people will disagree with me though ;)

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com