Re: Crush 2.0 abandoned
Hi,
On Wed, Aug 12, 2009 at 01:52:13PM +0200, Hector Oron wrote:
> Package source format (we wish) will allow to have foreign
> dependencies (build-cross-depends or bootstrap dependencies fields).
If we have a small enough change we might even shoehorn that into squeeze,
so we can start sending patches to Debian maintainers after the squeeze
release.
The "cross building" use case can be handled by simply adding a third
"magic" architecture name and have the Debian tools handle that as if it
meant a strict ("same" if I understood it right) dependency.
For Debian, this brings no real benefit for squeeze as they don't want to
cross-build, but it will allow us to merge the patches distinguishing cross
and native build dependencies back into Debian (the official autobuilders
use stable apt/dpkg to install build dependencies, so packages in unstable
need to be fully supported by the stable tools).
For squeeze+1, we can then push for "multiarch phase 2" which includes
declaring dependencies on foreign architecture packages, which will be
necessary for both firmware builds (which are currently handled by building
the firmware as an arch:all package on an e.g. ARM host) and cross compiler
bootstraps. Such packages could exist in emdebian's unstable for the time
being, and be added to Debian unstable after the squeeze+1 release (so
cross compilers will be built using the method we outlined in Cáceres).
> Multiarch solves many things, but it will not be ready for our needs on
> Squeeze, but it could be ready for Squeeze+1. What I (also Neil) meant
> it is better to work towards that approach than fix apt-cross perl
> bindings, dpkg-cross and patch all the packages to be able to cross
> build properly for Crush2.0 which will be deprecated after multiarch is
> ready. Did I make sense?
Yes.
dpkg-cross will not go away soon, but it needs to do considerably less for
multiarch packages. It already supports a very similar mode (cross2cross)
where it filters the file list only and creates an output package that is
arch:all -- if that is adapted to handle the multiarch paths similarly, it
should be enough to get us to squeeze+1. This change should happen before
squeeze. I can do that, but would prefer if someone who actually knows perl
looks at it (in principle: add regexes matching the multiarch paths and
handlers that copy the file into the same path in the target package; also,
the created package needs to Provide and Conflict with the original).
Simon
Reply to: