tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


David Holland <> 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

> 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

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,

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

Home | Main Index | Thread Index | Old Index