Recent advances in cross building src:perl

[Niko Tyni]

On Sun, Jan 24, 2016 at 03:59:45PM +0100, Helmut Grohne wrote:

> From a bootstrap testing pov, an experimental upload is probably not
> very useful, because there is no way to obtain perl-config-data in an
> architecture-generic way. The automated bootstrap tests that I am
> conducting cannot get this data unless it resides in a source package or
> in an arch:all package. I won't be able to cover perl in my tests as is.

I see.

> > In the long run, I can see cross building eventually replacing our
> > current somewhat half-baked new architecture bootstrapping support that
> > is the reason we need to roll our own horrific debian/rules and can't
> > use debhelper et al. I think I'd want to see how this stuff rebases on
> > a couple of upstream releases first before declaring it stable, though.
> 
> It does use things such as dpkg-architecture, which is written in perl.
> Is it really known that the perl packaging currently works without perl?

It certainly doesn't do so automatically for precisely the reason
you mention, but see the blurb at the start of debian/rules, and
debian/checkperl. It looks like the idea is that you can build the
perl binary, copy it to /usr/bin, and then proceed to build the full
package. This is inherited stuff, and I have no idea how well it works or
if the bits have rotted away over the years. Still, we've been carrying
on avoiding using perl to build perl as far as possible.

> Knowing that perl can be crossed once one has perl-config-data is
> already a big win. It means that there are no further issues around the
> corner. Obtaining perl-config-data still is difficult, so I'd like to
> see it go away in mid term already. I basically see three (supplemental)
> ways to get rid of it:
> 
>  * Fix Configure to require less of perl-config-data during cross
>    compilation to make one of the following options more feasible. For
>    example determining sizeof values #775940. Judging from the forwarded
>    upstream bug, it seems that upstream is slowly working on this.

Upstream has explicitly said it's a manpower thing. I expect volunteers
are welcome.

>  * Create another way to generate perl-config-data that works in a cross
>    compilation setting. This would essentially amount to maintaining a
>    large set of values and a mapping from autotools test results (which
>    can determine many of the settings) to perl test names.

Urgh. If this was easy, I guess it would be done already.

>  * Maintain the contents of perl-config-data in some arch:all or source
>    package.

This is basically the perl-cross-debian solution. I can see arguments
for embedding it in src:perl, but I'm not thrilled about the maintenance
burden. As is probably clear by now, I was hoping that storing the config
data as a build artefact into a separate arch-dep binary package would
be enough. If it isn't, I'd be inclined to keep it outside src:perl,
unless it enables us to massively simplify our debian/rules.

> All of the above require a better understanding of how the contents of
> perl-config-data vary among different architectures. In particular, how
> do these values vary on non-linux ports (e.g. hurd-any and kfreebsd-any)
> and maybe also on non-glibc ports (e.g. musl-linux-any and
> uclibc-linux-any). An experimental upload could give answers here, but
> publishing a diverse set of perl-config-data packages elsewhere would do
> the same.

Wow. Just getting linux-gnu-* to work seems enough for now... :)
-- 
Niko