On 20 Jan 2012 13:06, "Matthew Seaman" <m.sea...@infracaninophile.co.uk> wrote: > > On 20/01/2012 12:53, Chris Rees wrote: > > On 20 Jan 2012 10:20, "Matthew Seaman" <m.sea...@infracaninophile.co.uk> > > wrote: > >> > >> On 20/01/2012 09:18, Chris Rees wrote: > >>> On 19 Jan 2012 08:58, "Matthew Seaman" < m.sea...@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. > > > > Yes, I understand thae distinction between BROKEN and IGNORE, thank you > very much. So the BROKEN_FOR_ARCH variable family should ultimately set > BROKEN rather than IGNORE. Obviously. >
Sorry, missed that bit. Thing is... adding this change to bsd.port.mk will actually mean that instead of each BROKEN Makefile testing for it, *every* port's Makefile then tests for it. Chris _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"