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

Re: Recent advances in cross building src:perl

On Sun, 24 Jan 2016 20:15:46 +0200
Niko Tyni <ntyni@debian.org> wrote:

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

Note: automated bootstrapping of a completely new architecture is a
long, long, long way down the road for perl and this should *not* be
seen as a disincentive to put the config data for each supported
architecture into the archive *automatically* (and as soon as

We will benefit massively simply from having a history of config for
multiple architectures over multiple upstream version builds.

Helmut: I think you are being wildly unrealistic about what can
actually be achieved in any reasonable timeframe. Not having support in
your rebootstrap tests is no reason not to press ahead with this config
package approach as soon as possible. There are many many more steps
required before anything could be fully automated and we need to take
this one step first.

> > Knowing that perl can be crossed once one has perl-config-data is
> > already a big win.

It is a *massive* win compared to what we had before. There was *no*
guarantee that the perl-cross-debian support would work for any
architecture *& strict perl version* other than the ones tested. 5.17.1
worked, 5.17.2 did not. That's how often the data can change. I wish
there was time to fix this upstream but there have been numerous
attempts and it's still a long way off.

Do not underestimate the value of having historical config for all
architectures and all releases of perl after a certain flag day onwards.

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

... and have come and gone in the past. Hopefully, as each step makes
the objective easier, we will eventually get to a point where this can
be fully automated. IMHO that is extremely unlikely in anything other
than the long, long term. It is a *lot* of work and beyond the scope
of any one volunteer even at this stage.

We all want to see Configure needing no more data than a
typical ./configure and for that data to be munged by Configure into
the full set (which is largely a superset of the raw data in a myriad
of different contexts).

The problem is that this is a moving target and without a lot of work
upstream and an upstream method of re-balancing / testing / validation
at every release (possibly every commit), then work on any one release
is largely irrelevant to the next release.

So the correct solution is to have a arch:any config package that can
be tracked and which can deliver what was hoped for from
perl-cross-debian - historical context. The objective for a new
architecture is then to build an old-ish version of perl (say stable),
using that data to pin point where this arch differs from all the

It is manual and there is no realistic prospect of moving that on to a
fix which can be automated upstream *without* that historical context -
and probably doing a new architecture bootstrap manually using it, at
least once.

Fixing Configure upstream is the only viable solution - to do that
needs the historical context and a lot of work.
> >  * 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.

Absolutely - that isn't even worth considering as a solution.
> >  * Maintain the contents of perl-config-data in some arch:all or
> > source package.  

Please no. It has to be arch:any. Don't repeat the perl-cross-debian

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

The whole point of doing this in src:perl is to get the *data* on every
supported architecture at every release. To build the matrix, to find
the commonality. Nobody (upstream or Debian) has any idea where that
commonality lies, yet.

The maintenance burden of an arch:all package is prohibitive - I know,
I tried it. This config *must* be arch:any to be of use.
> > 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... :)


To get that better understanding, we need the arch:any config package,
that is precisely what will give us real, usable, verifiable data on
which values are OS-specific, which are arch specific and which are
remappings of other values into a new context.

Even then, this data must be compared in-memory, not as files. The
upstream changes routinely change the ordering of the output which
makes the output of `diff` useless. So a helper program will be needed
to make sense of the data. Nobody can even start on that until the
config is available and tracked over at least a couple of perl uploads.


Neil Williams

Attachment: pgpivN0QT9Zzy.pgp
Description: OpenPGP digital signature

Reply to: