On Sun, 22 Jul 2012 18:01:05 +0100 Wookey <woo...@wookware.org> 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/
pgpg709runOyv.pgp
Description: PGP signature
