Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Mon, 30 Oct 2017 20:13:51 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Jakub Jirutka <jakub@jirutka.cz>
Cc: William Pitcock <nenolod@dereferenced.org>, alpine-infra@alpinelinux.org
Subject: Re: Building community/cargo, build-edge-x86_64 is stuck
Message-ID: <20171030201351.5411c971@vostro>
In-Reply-To: <CB840A20-A016-4344-9F26-5AEDCEC26C93@jirutka.cz>
References: <700B1EC2-05EB-433D-B8CA-886DDF4CAE70@jirutka.cz>
	<CA+T2pCE-B2P_Js=hc+X-UjvptJTMizX_nUZ4szzBodHZLi3Ktg@mail.gmail.com>
	<CB840A20-A016-4344-9F26-5AEDCEC26C93@jirutka.cz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/6W4AAqysJd+y76rVAHhAoOS"; protocol="application/pgp-signature"

--Sig_/6W4AAqysJd+y76rVAHhAoOS
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 30 Oct 2017 17:39:19 +0100
Jakub Jirutka <jakub@jirutka.cz> wrote:

> > Look at the haskell + cabal packaging for inspiration, it is a
> > similar situation, and is policy compliant. =20
>=20
> 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=3D"$pkgname"`, so it depends on itself. There used
> to be package ghc-bootstrap, but it was not used anymore (and even
> that couldn=E2=80=99t work without manual intervention). I asked fabled a=
bout
> 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.
>=20
> The same situation is community/rust. I even mentioned this in my
> email.
>=20
> 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 =20
>=20
> 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.
>=20
> 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

--Sig_/6W4AAqysJd+y76rVAHhAoOS
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEMFbxI+htokjmnosIJeI3SXQya/sFAln3a98ACgkQJeI3SXQy
a/uo/w//UNUFsqRoXB8bQwhlBZqtRUjbFNfSVgBzeVYCuGbyQQfu1CD1BYiL+Aef
Zv5E0MeZgQKkT/RzR06P8A7sK3UEva0Vg2mxOgo267JWDKROuxeFEbxqLyxAwztI
Xt8wNElUNzMksdX9Jg/8qhSBFFcEfBQbiTR4dKIe8g+bxKmWdee1O3/k3rvtYp8u
TyuCgnH0X11jAga12Q1/AHaI6E0Fc3D+YFtvMtSXYCyB8AfUVLn4sKQodzOiYuEK
w+zZ6PmYI2uYfDOEdoV2U1PkWK0KnZgxqRlixDwQlSRf4vwAUBvneI6DfeOnsuAJ
mfToNexjqpijxJUFBNNpV5ogiZf1J81wabhnA5Rt4CXha2c3bPCQ4ZvddXIDm++U
xfzTR62C91g0EzyF2p/iaJ5Fbar07EvChHDa+poUm4wGBPh74yAWR87vLuLCgkYf
5mlLDWYEEPHqcXDEjMd6vV+9tw/a9LlYVp4lNGSuCi4ZaieRdK4hgOBnfm5XmfgV
ICl+gb+iVlSvMo9ADzN1shHYZSUF8H/DW3+RhYG1ypZcCScU6BHxID1XQbUBmaUW
Ok8psjQVz1AVW+J+5/bCLMtCrQWP5oe0lOwJwKaZaRzL4aPT9PRRkrC8rY0/zuw/
fm9aqDIz45DplX9qL+DHOgufuHMOmYPcKqvkcZNFFmOfs6rCZjg=
=qQqw
-----END PGP SIGNATURE-----

--Sig_/6W4AAqysJd+y76rVAHhAoOS--