Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jan 2012 13:14:05 +0000
From:      Chris Rees <utisoft@gmail.com>
To:        Matthew Seaman <m.seaman@infracaninophile.co.uk>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: with the cvs history? trying to help INDEX builds.
Message-ID:  <CADLo83_qVjwsNg-sTzC4ANsyghZpqDm09WAapRv4aP7VZJqJcg@mail.gmail.com>
In-Reply-To: <CADLo838bMSv9jaX=gvW0t5KUBHPDF-PffmSnLdwoxqRJxQyyNQ@mail.gmail.com>
References:  <4F177264.3090708@freebsd.org> <4F17DB1C.6080503@infracaninophile.co.uk> <CADLo83-WtVmyGHM=O4FbTNbDy9h=A1t111bP6eYc%2BTL8-RGmuA@mail.gmail.com> <4F193FD5.8070208@infracaninophile.co.uk> <CADLo83-n_C9h-eLSMZ%2B23s_piocyNuTy_VsNxkKK2RZAA_wG-Q@mail.gmail.com> <4F1966C2.6090908@infracaninophile.co.uk> <CADLo838bMSv9jaX=gvW0t5KUBHPDF-PffmSnLdwoxqRJxQyyNQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 20 Jan 2012 13:06, "Matthew Seaman" <m.seaman@infracaninophile.co.uk>
wrote:
>
> On 20/01/2012 12:53, Chris Rees wrote:
> > On 20 Jan 2012 10:20, "Matthew Seaman" <m.seaman@infracaninophile.co.uk>
> > wrote:
> >>
> >> On 20/01/2012 09:18, Chris Rees wrote:
> >>> On 19 Jan 2012 08:58, "Matthew Seaman" <
m.seaman@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83_qVjwsNg-sTzC4ANsyghZpqDm09WAapRv4aP7VZJqJcg>