Hi Niko,
Thanks for communicating your intentions early!
On Sat, Apr 16, 2016 at 12:20:08PM +0300, Niko Tyni wrote:
> (cc'ing the debian-cross list, but please let me know if there's a
> "right" place to discuss architecture bootstrapping.)
Partially. As far as I know there are two independent bootstrap efforts.
One is focused on (re)creating Debian architectures by reusing existing
ones. For this one, we generally use debian-cross@l.d.o. The other is
focused on (re)creating Debian architectures using non-Debian systems of
the same architecture. The latter is not using cross building and is
mainly lead by Daniel Schepler (Cced).
> Now, I haven't really ever tried this myself, and it may well have
> bitrotted. Clearly bootstrappers are managing somehow, though, given that
> new Debian architectures seem to be popping up yearly or so. I wonder
> if the above process is actually used anywhere, or if people are doing
> something totally different to get working perl binary packages together?
I cannot speak from experience here, because my bootstrapping efforts
mainly considered perl an unsolved problem for cross compilation. So
this question probably needs an answer from people who practically
bootstrapped architectures, such as Wookey or Christian Svensson.
It seems that the currently favoured way to bootstrap perl is to
natively build a stage1 package, integrate it into the perl source and
then cross build perl. If this method is here to stay, then maybe the
stage1 build should keep work without access to perl? This sounds like
it would complicate matters a lot, so it must be carefully considered
whether it is indeed necessary.
> So if we started to build-depend on debhelper and therefore transitively
> perl, would anybody actually care?
The cross builders certainly wouldn't. It seems that we should consider
Daniel Schepler's method and the stage1 build here.
> I note that recent progress on src:perl cross build support has promise
> in this area and might well be the final solution. However, it's new enough
> that I wouldn't really want to count on it quite yet.
>From my experience with libgpg-error[1], I am not very enthusiastic
about embedding configure results in the source package. The amount of
work it creates both on the bootstrapper's side and on the perl
maintainer side is immense. Unlike libgpg-error, it needs to be
repeated for each major perl release. (And this is the only downside I
see.)
That said, I do recognize that it makes crossing perl work today, which
other approaches do not achieve. The approach very much solves crossing
perl practically. Thank you for exploring it despite the workload it
creates.
Helmut
[1] It needs some header for each architecture, see
https://sources.debian.net/src/libgpg-error/latest/src/syscfg/.
At this time, it still lacks e.g. nios2 and powerpcspe support.
