Re: Bug#180128: state of integration of dpkg-cross into dpkg
Hi!
On Sun, 2012-07-22 at 19:23:44 +0200, Guillem Jover wrote:
> On Sun, 2012-07-22 at 18:01:05 +0100, Wookey wrote:
> > +++ Neil Williams [2012-07-22 17:05 +0100]:
> > > On Wed, 18 Jul 2012 19:11:38 +0200 Guillem Jover wrote:
> > > > So, was checking this (and also the dpkg roadmap) and was wondering what
> > > > else is still missing to be merged from dpkg-cross? If the only problem
> > > > is the listed below, then it'd seem this bug has been resolved and it
> > > > can be closed.
So I'm doing this now, see below for rationale.
> > > Therefore, I think this bug will need to remain open, unless dpkg
> > > maintainers do not wish to integrate the cross architecture-specific
> > > metadata at all. (This data does not change until a new port is
> > > accepted by dpkg or an old port removed, at which point it is just a
> > > single file addition/removal containing data provided by the porters.)
>
> > > e.g. for armel:
> > > ac_cv_c_bigendian=no
> > > ac_cv_c_char_unsigned=yes
> > > ac_cv_sizeof_long_long=8
> > > ac_cv_sizeof_unsigned_long_long=8
> > > ac_cv_sizeof_long=4
>
> Something that has crossed my mind in the recent past is that cputable
> has most of this data, but not all, and it could make sense to add
> more information so that the architecture ABI is crystal clear from
> the tables alone. dpkg-cross or crossbuild-support or whatever could
> then generate an autoconf cache file at build time from the dpkg tables
> for example. Because I'd assume there's other cached values that will
> end up there and those would certainly not be appropriate for dpkg.
I think the current understanding is that these are derivable by
autoconf checks even when cross-building, at least with recent enough
autotools, so the correct fix is to update projects.
Also I've been pondering about these values and I'm not sure anymore
they belong in the arch tables. Many of these are C-type specific, and
might or might not apply at all to other run-times, of course we kind
of base our ABI based on the libc, but still.
> > I don't think that dpkg is the right place for this data. We want to
> > be able to update it easily without having to mess with important
> > things like dpkg. The core cross functionality is now in dpkg and apt.
> > We should discuss where remaining stuff like autoconf cache variables,
> > triplet-prefixed commands like <triplet>-pkg-config and
> > <triplet>-config scripts, cross-build-essential package lists and the
> > like should live, but I don't currently see good arguments to put any
> > more of it into dpkg.
>
> Except for my comments above, I tend to agree with this.
Yeah, so given the above, I'm just going to close this now, as
everything else should already be supported in dpkg. If there's
something else still missing or lacking an already filed report, let's
open a new one to track it.
Thanks,
Guillem
Reply to: