Re: PKG_SKIP/FAIL_REASON

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Tue, Dec 30, 2014 at 12:38:15PM -0500, Greg Troxel wrote:
 > > I'm not especially happy with the name BROKEN_EXCEPT_ON_PLATFORM; it
 > > could be WORKS_ON_PLATFORM, but (a) I'd kind of rather have the word
 > > BROKEN in it, and (b) that's too affirmative (not broken is not the
 > > same thing as known to be working...) and so far I can't think of
 > > anything else.
 > 
 > Do you have an example for this?   It seems to me that there are some
 > packages whose upstreams document that they only work on a limited
 > number of platforms; those should be SKIPped on other platforms.  Or
 > perhaps the documentation is implicit.

There are a number of packages that demand explicit configurations for
OS and CPU combinations. Some of these are compilers where porting to
another CPU would be a fairly big project; but most of them are just
crappy build systems where filling in a new config usually isn't hard
but tends to require access to the platform. In this case, only the
configurations that exist will build and the rest are BROKEN. And,
given how many platforms we have in pkgsrc, it is not reasonable for
these to enumerate the platforms that are missing.

If you search you'll find a lot more uses of ONLY_FOR_PLATFORM than
NOT_FOR_PLATFORM and I think this usage covers most of them.

There is a fairly fine line between broken and unsupported sometimes;
my rule of thumb (which is probably more aggressive than yours) is
that anything that can be rectified by reasonably noninvasive
patching, or won't take more than an evening or so to sort out, is
broken; and anything that needs major restructuring or a large
development project, like retargeting a compiler, is unsupported. This
is partly motivated by wanting to be able to use the broken build list
as a source of short hacking projects for when I'm bored but too tired
to do substantive things. :-)

I'd probably also use BROKEN for nontrivial cases where the package is
important enough that to the extent we care about the platform we
should probably try to get the work done; e.g. firefox, or something
analogous to crosscompiling Perl.

 > About compilers: I agree with Edgar that there is a distinction between
 > needing features a compiler doesn't provide and running into bugs.

There is; but it occurs to me that there's another critical
difference, which is that regardless of what the difficulty with the
compiler is, we aren't likely to be fixing the compiler and so getting
the problem reported through channels isn't that important. I guess
there's a family of compiler issues that one might work around by
patching the victim package; but I doubt any of these are currently
marked NOT_FOR_COMPILER.

 > But
 > it could also be that specifying required compilers is part of a
 > different infrastructure (which needs an overhaul, but that's separate),
 > and the BROKEN mechanism only about bugs.

Do you mean that there should be a BROKEN_ON_COMPILER that triggers
PKG_FAIL_REASON instead of choosing another compiler, and is thus
substantively different from NOT_FOR_COMPILER? I'm not sure what I
think of that.

But in any event the _COMPILER stuff is separable so I'm not going to
do it up front. So let's keep talking...

 > (Other than that, your notion sounds good to me.)

ok good :-)

If nobody objects I'll probably go ahead and commit tonight.

-- 
David A. Holland
dholland%netbsd.org@localhost