with the cvs history? trying to help INDEX builds.

[Chris Rees]

On 20 Jan 2012 10:20, "Matthew Seaman" <m.seaman at infracaninophile.co.uk>
wrote:
>
> On 20/01/2012 09:18, Chris Rees wrote:
> > On 19 Jan 2012 08:58, "Matthew Seaman" <m.seaman at infracaninophile.co.uk>
> > wrote:
>
> >> On 19/01/2012 01:31, Michael Scheidell wrote:
>
> >>> anyway, worth the cycles?
> >>> take out -.include <bsd.port.pre.mk>; -.if ${ARCH} == "sparc64"
> >>> -BROKEN=        Does not install on sparc64
> >>> -.endif
> >>> and replace it with NOT_FOR_ARCHS=    sparc64 ?
>
> >> I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
> >> handle this sort of thing.  By my calculations there are 28 ports that
> >> set 'BROKEN' because of architecture incompatibility on my amd64
> >> system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS
or
> >> NOT_FOR_ARCHS.
>
> > No, it's not worth it :)
> >
> > This means we won't be able to differentiate between BROKEN and IGNORE.
>
> Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
> {NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
>
> Actually I take your point, that it should be possible to distinguish
> between ports that permanently won't work on some architectures by
> design, and ports that temporarily don't work because of mistakes or
> broken dependencies or so forth, and that are expected to be fixed
> sooner rather than later.  Unfortunately those two cases are already
> pretty confused.  For instance (arbitrarily picking out a few grep hits):
>
> ./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64=
 "GCC-related
> build error"
> ./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64=      does not compile
> ./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON=       Does not compile
>
> Where 'does not compile' or 'fails to install' are similarly the most
> popular reasons given for arch-related brokenness using the BROKEN
> variable.  Given the banal and uninformative nature of such reasons,
> there's no easy way to tell if this is a temporary condition or not.
>
> Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set of
> variables documented alongside the other ..FOR_ARCH variables?

Occasionally someone runs an exp- for sparc64 (lol) etc.

They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS sets
IGNORE.

Ports marked this way (incorrectly) will never be tested, and thus never
marked fixed.

Chris