Re: CVS commit: pkgsrc/security/libfido2

[Greg Troxel <gdt%lexort.com@localhost>]

"Jonathan Perkin" <jperkin%netbsd.org@localhost> writes:

> @@ -20,6 +20,10 @@ BROKEN_EXCEPT_ON_PLATFORM+=	Linux-*-*
>  BROKEN_EXCEPT_ON_PLATFORM+=	NetBSD-*-*
>  BROKEN_EXCEPT_ON_PLATFORM+=	OpenBSD-*-*
>  
> +# This library does not yet support illumos, but its developers and users
> +# strongly value bulk build reports rather than hiding breakages.
> +BROKEN_EXCEPT_ON_PLATFORM+=	SunOS-*-*
> +
>  USE_LANGUAGES=		c
>  USE_TOOLS+=		pkg-config mandoc
>  CMAKE_ARGS+=		-DBUILD_EXAMPLES=OFF

Sorry that I misinterpreted; I thought we had converged on understanding
what the real portability issues are with libfido2 and marking them (and
obviously openssh should build without it when libfido2 does not work).

Thank you for putting in a comment that explains this to the next person
to run into issues, who will undertand that intent.

I think there's a larger point of disagreement lurking here, and it
might be helpful to talk about it explicitly.  We have BROKEN_ON to mark
packages that ought to work and don't.  But for SunOS, you wish them to
fail rather than be marked.

The pkgsrc guide currently says:

  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. If the package builds and
  runs on a small handful of platforms, set BROKEN_EXCEPT_ON_PLATFORM instead.

This text was added in January 2015; there is earlier text about BROKEN
in 2006.  Omitting BROKEN_ON for SunOS is contradictory to the guide as
it stands.

I see concerns that different people might have:

  1) package not marked BROKEN

    a) time spent trying to build it

    b) users posting "build failed" messages

  2) package marked BROKEN

    a) not showing up as failed in bulk build

    b) not being retested in case it transitions to working (e.g. by
    some update done by someone who tested on a different platform,
    after upstream gets the support it ought to have)

I don't see how to address 1a/1b without something that is essentially
BROKEN.

2a can be addressed by bulk builds showing the package as failing
without trying it.

2b can be addressed by having a mk.conf flag IGNORE_BROKEN_ON that
causes BROKEN_ON_* BROKEN_EXCEPT_ON to be ignored, so that it's as if it
were not set.  (Similarly for IGNORE_NOT_FOR.)   Except that in addition
to ignoring, the build report could loudly say that a BROKEN_ON/NOT_FOR
package built.


My view, not yet fully baked, is that if you want the
reporting/etc. then adding IGNORE_BROKEN_ON is pretty easy, and lets
everybody have what they .


How do you think we should deal with category 1 concerns?

Do you think we should remove the concept of BROKEN_ON entirely?

Do you think we should have a documented list of platforms (determined by
some consensus mechanism) that we don't set BROKEN_ON for?

Do you think IGNORE_BROKEN_ON is a reasonable approach?


Greg