Mail archive
alpine-infra

Re: Building community/cargo, build-edge-x86_64 is stuck

From: Timo Teras <timo.teras_at_iki.fi>
Date: Mon, 30 Oct 2017 20:13:51 +0200

On Mon, 30 Oct 2017 17:39:19 +0100
Jakub Jirutka <jakub_at_jirutka.cz> wrote:

> > Look at the haskell + cabal packaging for inspiration, it is a
> > similar situation, and is policy compliant.
>
> Have *you* looked at ghc (haskell) package? I did some time ago (and
> now), tried hard to figure out how does it build. There is
> `makedepends_build="$pkgname"`, so it depends on itself. There used
> to be package ghc-bootstrap, but it was not used anymore (and even
> that couldn’t work without manual intervention). I asked fabled about
> it and he explained me that ghc-bootstrap was only temporary for
> initial bootstrap, now ghc depends on itself and it must be probably
> manually installed on the builder when bootstrapping.
>
> The same situation is community/rust. I even mentioned this in my
> email.
>
> Unfortunately the bootstrapping (and cross-compilation) process is
> still not documented anywhere, so I can refer only to information
> that I was told by more competent people like fabled.

There's two separate "bootstrap" problems.

1) bootstrapping new stable branches, or new architectures. These are
usually cross-compiled using some existing Alpine build with the
scripts/bootstrap.sh. Doing this follows relatively working set of
rules.

2) bootstrapping packages that are self-dependent. This is annoying,
and starting to be increasing number with different languages. rust,
ghc etc. just to name a few.

Now go and java have been special, because for them there's been a way
to bootstrap them without binary builds. E.g. early go versions is
still go-bootstrap package for x86_64, which can be used to bootstrap
go. Or java can be done via gcc-java -> openjdk7 -> openjdk8. But
usually they now require themselves to build a version of compiler with
all features. So go wants to build it self with go. Especially when
targeting more "exotic" architectures than x86_64.

Now rust, ghc and some others are nasty. To have been able to produce
the first Alpine package has been impossible without existing ghc
compiler. So for ghc, we added ghc-bootstrap which was basically
Debian/docker produced binary blobs packages. And used to that produce
the first ghc compiler on x86_64. Since we don't want binary blobs like
that in aports, we dropped it right after ghc was built. All other
architectures were cross-compiled using alpine x86_64 ghc to target new
architecture.

> > A solution would be to take a copy of the cargo package from
> > distfiles.alpinelinux.org
>
> This is actually a good idea. I can keep it as it was before, just
> use our cargo binary instead of now non-existence binary from the
> upstream.
>
> fabled or ncopa, could you please explain how is ghc and similar
> packages handled? Ideally directly on wiki, or just via email and I
> will copy it to wiki.

This is complex topic as the answer to previous question implies. And
it needs package specific insights.

But basically, if there's maintainable bootstrap procedure without
self-dependency, we are happy to have the "$pkg-bootstrap" package
doing this. But if the package is hardwired to require itself for
compilation, the only practical option is to do "$pkg-bootstrap" which
is basically binaries produced from foreign system, use that to build
the package first time, and then drop "$pkg-bootstrap" and makedepend
the package to build itself.

Hope this explains my standpoint. And reasoning on the different
approaches between different packages.

Timo

Received on Mon Oct 30 2017 - 20:13:51 GMT