Re: Bug#180128: state of integration of dpkg-cross into dpkg

On Sun, 22 Jul 2012 18:01:05 +0100
Wookey <[email protected]> wrote:

> +++ Neil Williams [2012-07-22 17:05 +0100]:
> > One unresolved issue is the cache values and architecture support:
> > where to put the cross- config settings currently implemented
> > in /etc/dpkg-cross/cross* which pass the architecture-specific values
> > to autotools projects. CC'ing debian-embedded for more input on
> > that. 
> 
> It was sugested at the multiarch-cross BOF at debconf this year that we
> create a 'crossbuild-support' package to take over these various glue
> functions from dpkg-cross. That could just stay named 'dpkg-cross' for
> simplicity but if we are going to drop all the cross-conversion
> functionality and add a load of other stuff, a name change makes
> sense.

OK. I don't mind what the package name is, as long as it Breaks: xapt.
If it's not dpkg-cross, it will also need to Conflict: dpkg-cross

The cross-conversion functionality can only be dropped once the
"critical mass" of -dev packages are implemented.
 
> > 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.)
> 
> I don't think that dpkg is the right place for this data. 

The architecture-specific data? Is that really subject to change? True
the package-specific stuff is going to change and is not useful in
dpkg, but once a port has been accepted, the chances of the size of a
long long being changed are slim (and a serious problem).

> We want to
> be able to update it easily without having to mess with important
> things like dpkg. 

True - for the package-specific stuff. Equally, the package-specific
stuff could actually be patched into the relevant packages which is a
better place for it - eventually.

> The core cross functionality is now in dpkg and apt.

with the sole exception of the size of a long long for DEB_HOST_ARCH
etc.

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

The package-specific stuff does not need to be lumped in with the truly
architecture-specific variables.

Most of the package-specific cache variables are not also
architecture-specific, separating those out means less files need
updates and if we do get the package-specific cache values into the
packages, the whole cache problem becomes more manageable.

This is a long-term goal, it will take until Wheezy+1 to even get that
"critical mass" of -dev MultiArch packages.

> If we are agreed on that then this bug is indeed closed. 

So is it worth separating out the architecture-specific cache values?

It's not easy to do until other changes are in place but I think it
should be done.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlAMN98ACgkQiAEJSii8s+NPJgCgiObnaREoO8/w+yoUyrEe9PkN
qi8AniNk3DQJqDlXMBlPPhE4/a2Q+WPD
=orZt
-----END PGP SIGNATURE-----