[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Recent advances in cross building src:perl

On Sat, Jan 23, 2016 at 10:45:08PM +0200, Niko Tyni wrote:
> I've been working on cross build support for src:perl, which has
> been a sore point for quite some time. Current results are on the
> ntyni/cross-5.22 branch on alioth (but might still get rebased/rewritten):

This is awesome news for bootstrappers.

> Summary: Configure still needs runtime probes, but the resulting probed
> configuration data can be fed into a cross build with a separate binary
> package, currently called perl-config-data. This is the same approach that
> Neil Williams worked on with src:perl-cross-debian a couple of years ago,
> but we now build the package from src:perl itself.

I concur with Neil Williams that the immediate value of perl-config-data
is to obtain the relevant values for a broad architecture set.

> I'm not sure if it's viable to upload this into experimental at
> this point; the buildds probably don't have #809730 fixed yet,
> do they?  Without that fix, sbuild applies the cross build dependency
> on perl-config-data to native builds too and bails out straight away.
> Also, we'll be needing experimental for staging 5.24 in a few months so
> maybe it would be better to use a custom repository for testing this?

>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.

> 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?

> In any case, I'd be interested in comments and thoughts on this.
> Is it useful, or just a worthless workaround as long as the Configure
> issues remain unsolved?

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.
 * 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.
 * Maintain the contents of perl-config-data in some arch:all or source

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.


Reply to: