David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > 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. I see your point. So if a package supports only a tiny number of platforms, BROKEN_EXCEPT_ON_PLATFORM seems ok. Once it has more than a few, it seems the burden should flip to list broken ones. I suspect that we only really need BROKEN_ON_PLATFORM entries for platforms where somebody actually does a bulk build. Overall I have a preference for accumulating verified BROKEN facts at the expense of attempting to build on platforms where static analysis indicates failure will occur. > 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. OK - the point is really that it's about missing config entries for autoconf/etc. that in theory would work. > 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. :-) That's a reasonable view. I tend to push more of the responsibility to upstream --- pkgsrc isn't broken for failing to build if a human following upstream's instructions can't reasonably easily succeeed. Perhaps the SKIP entries should have an estimate of hours to fix, and we can all be happy. > 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. That's blurring the FAILED/SKIPPED line, but in a way that seems useful. > > 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. This gets to the point I was trying to make and obviously haven't yet... > > 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... No, what I meant is that we have a complicated situation already with packages, languages and compilers, and it's well beyond what can be handled with BROKEN/etc. * We already have a notion of language, e.g. c99. But a program that needs c99 often needs c99+foo, for some smallish foo which might be compiler extensinos. It so happens that modern clang will have extensions from modernish gcc, because so many things need them. * We already have a notion of GCC_REQD. This is about many things, but generally that a package can't be built with old gcc, either because of known bugs or because it uses too-new features. * We've talked about GCC_INCOMPATIBLE or something (I can't find the messages from the discussion about 1.5 months ago) for cases when e.g. gcc 4.5 or newer is ok, but 4.8 is known not to work. The difference with BROKEN_ON_PLATFORM is that when building a package for a platform, the platform is fixed. But the compiler being used isn't really fixed, because we have infrastructure to change it. Right now we seem to hold the compiler family fixed (gcc vs clang, and other compilers of lesser and fading importance). But we do have a notion, at least in gcc, of having to have a newer version. So, I think we should etiher: A) decide to treat the compiler as fixed, and just fail if it isn't ok, or B) have some compiler choice within a family mechanism, probably a minimum version and a set of versions that are not ok, with pkgsrc being free to use any versions >= minimum not in the failing set. (And if you don't like the results, fix the failing set.) Right now this might be only for gcc, or C) Have something like the within-family compiler choice, but extend it to across families, so that even if configured to build with clang a package marked as not working with clang would get built with gcc. One reason this is tricky is that we have, operationally, different aproaches based on compiler. When a pacakge fails to build with some version of gcc, we just say "oh, it neds this other version". When a package fails to build with clang, we say "oh, this doesn't follow the C spec and needs to be patched". One approach is more expedient and one more righteous ;-) So I think you're talking in terms of marking packages broken with specific compilers or members of compiler families. I am primarily thinking about option B, where the BROKEN option applies to entire families, but not within a family.
Attachment:
pgpKWFTCki9lG.pgp
Description: PGP signature