Subject: Re: BROKEN* and CONFLICT - the final decisions
To: Dan Langille <dan@langille.org>
From: Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
List: tech-pkg
Date: 01/12/2001 14:19:34
On Fri, 12 Jan 2001, Dan Langille wrote:
> We will use BROKEN_ARCH to indicate what architectures a particular 
> port is broken on.
> 
> ONLY_ON_ARCHES will indicate those architectures upon which the 
> package will work.  It is the complement of BROKEN_ARCH.

How about s/BROKEN_ARCH/NOT_FOR_ARCHS/ for some consistency?

Or even use the NOT/ONLY_FOR_PLATFORM from NetBSD, which matches against
MACHINE_PLATFORM. MACHINE_PLATFORM is defined as

MACHINE_PLATFORM?=      ${OPSYS}-${OS_VERSION}-${MACHINE_ARCH}
OPSYS!=                 ${UNAME} -s
OS_VERSION!=            ${UNAME} -r
MACHINE_ARCH is defined my make(1) at compile time.

This scheme works fine already for NetBSD on all our platforms, as well as
for Solaris and Linux as well as for determining special OS versions.

E.g. you can do something like:

.if ${MACHINE_PLATFORM:MNetBSD-*-i386} != ""
PKG_JVM?=               jdk 
.else
PKG_JVM?=               kaffe
.endif

But why do some research when reinventing the wheel is so much easier? ;)


> OpenBSD-ALL: Nasty evil use of mktemp()
> NetBSD-i386: Arbitrarily felt like breaking it on a clean arch. ;)
> ALL-alpha: Code seems to die on 64bit number mulching.

Also, why not use patterns that can be used against make(1)'s :M
modifier? I guess matching  "ALL" is more of a problem there. 
See above. 

If you want a platform-dependent broken string, I'd suggest
BROKEN_ON_PLATFORM for consistency. But then I'm not sure we need to do
things that fine grained. ``Stepwise refinement'' comes to mind here, and
maybe this can be adopted when actual need arises.


> ONLY_ON_PLATFORM on the other hand refers to broad platform 
> support and theimplicit lack thereof.  Probably this one could be good 
> for ONLY_ON_ARCH and ONLY_ON_OS separation, simply because 
> it's implicit behavior is to co-ordinate on a table.

Um, PLATFORM should include ARCH and OS, so there's no need for seperate
ONLY_* definitions.


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>