Subject: BROKEN* and CONFLICT - the final decisions
To: None <>
From: Dan Langille <>
List: tech-pkg
Date: 01/12/2001 18:45:38
I've been going through the BROKEN thread 
and I've tried to summarize the points with a view to including them in 

It appears there is no need for a CONFLICT (or similar) flag as we are 

Please comment on what I've included below.  As these points have 
already been discussed, please only respond if what I've written is 

We have 48 hours to discuss these issues and then update the page 
with our decisions, unless something HUGE comes up.

The BROKEN flag will specify that a package is broken on all platforms 
and architectures.  BROKEN will not be used to indicate a conflict or 
incompatibility with some other package.  Such conflicts can only be
determined at install time and on the machine in question.

*** How are determining and handlling a conflict exists ***

We discussed how some packages conflict when others were installed, 
and how fake helped to solve that problem.  We decided fake (as 
implemented in OpenBSD) is a great thing.  *** ARE WE GOING TO 
USE IT ***

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.

make list-broken can be used to obtain a list of the broken flags.  Here's 
an example:

bash-2.04$make list-broken

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.

Part of the reasons for adopting these concepts is to allow sites such 
as <> to obtain broken information.

We will also use ONLY_ON_PLATFORM in addition to BROKEN* 
because of the two common uses of each.  Broken stuff usually refers 
to specific problems that can be remedied, but are basically defects, 
not lack of platform support.

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.

Dan Langille
The FreeBSD Diary -
       FreshPorts -
     NZ Broadband -