with the cvs history? trying to help INDEX builds.

Matthew Seaman m.seaman at infracaninophile.co.uk
Fri Jan 20 13:06:22 UTC 2012


On 20/01/2012 12:53, Chris Rees wrote:
> 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.
> 

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.

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120120/7d1654ec/signature.pgp


More information about the freebsd-ports mailing list