Re: Updating plans of lang/ghc

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

On Wed, Jan 08, 2014 at 02:29:57AM +0900, PHO wrote:
 > I'm the one who has maintained wip/ghc, and I became a NetBSD
 > developer just recently.

Good to meet you finally :-)

 > There are currently two competing plans for updating lang/ghc, namely
 > lang/ghc-bootstrap and lang/ghc7. I think there are pros and cons for
 > these plans but let me first clarify the starting point of wip/ghc
 > bootstrap kits, which support the following 5 platforms:
 > [snip]

That's good information to have.

The chief concern with the provenance of binary bootstrap blobs is
whether the machine they were built on was adequately secured;
anything built on an owned machine might be trojanized somehow, which
is particularly problematic in the case of compilers. (And, well,
there's also the possibility that the person who built them might have
intentionally trojanized them, unlikely as that is.)

Now that you're here we can hopefully sort this out satisfactorily --
I have no desire to sink a lot of effort into updating ghc step-by-
step if it can be avoided.

 > I like the idea of lang/ghc-bootstrap. It is fairly attractive to have
 > a bootstrap kit installed as an usual pkgsrc package.

The reason I settled on doing that is that one of the major problems
over the last few years (and the chief reason ghc hasn't been updated)
is that there wasn't any precooked way to make bootstrap kits.
kristerw made them, as far as I know by hand for each new version; so
when he stopped having time nobody else knew how and he couldn't
readily send the directions to anyone else either.

The other advantage is that by making it a package, you automatically
get bootstrap kits compiled by the official TNF build hosts, or
whatever other binary package sources you already trust. This seemed
like a good plan.

 > The one thing I am concerning about is that users will have to find
 > and install a binary package if they want to build lang/ghc
 > themselves, otherwise they'll end up standing in front of a
 > circular dependency.

The idea is that ghc-bootstrap depends on ghc (used for building) but
ghc does *not* depend on ghc-bootstrap; instead once in a while
someone takes the ghc-bootstrap package from the build host and posts
it as a distfile in MASTER_SITE_LOCAL, and updates the distfile
information in the main ghc package. I think this avoids most of the
problems that otherwise come up.

There is one problem with the current ghc-bootstrap (other than it
being an old ghc), which is that it is dynamically linked against
libreadline and libgmp. This means that the next time readline and/or
gmp get their major versions bumped, the whole thing crashes out.

I was intending to correct this before the 2013q4 branch, but wiz cut
the branch without advance warning so I didn't get it done in time.

Also I ran into problems: it seems that disabling readline and telling
it to build with its included gmp (best available option in 6.8) is
not sufficient to produce an output package that doesn't depend on
pkgsrc readline and gmp. And it's hard to tell if it will be able to
build a new ghc this way anyhow -- I suppose I can create a chroot for
the purpose and artificially bump the readline and gmp major versions.
The conclusion I'd come to was that I should include copies of the
library images in the bootstrap kit and hope that it can be sorted out
with LD_PRELOAD when the time comes.

 > But how about ones that
 > were covered by lang/ghc but not by wip/ghc, namely Darwin/i386,
 > OpenBSD/i386 and SunOS/i386? Can anyone do the stepwise upgrade or
 > cross-compilation of 7.6.x for them? If not, is it OK for us to drop
 > support for these ones?

jperkin@ says the Solaris i386 one doesn't actually work, so it can be
dumped. I think he's using wip/ghc and made Solaris bootstrap kits for
it.

As for OpenBSD and MacOS... it will be much easier for someone to
crosscompile a recent version when/if they get around to it than to do
the long upgrade series. So if we're going to move to your bootstrap
kits, I think we can drop those too.

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