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 practical). 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 others. 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 approach. > 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpivN0QT9Zzy.pgp
Description: OpenPGP digital signature