Re: Crush 2.0 abandoned
+++ Neil Williams [2009-08-05 16:53 +0100]:
> On Wed, 5 Aug 2009 14:52:22 +0000
> Prince Riley <wmarketing3@gmail.com> wrote:
> >
> > We are all very glad and appreciative of the great work you've done
> > so far. We all understand and respect your decision and wish you the
> > best as you try to recover your health.
As is abundantly clear Neil has done an extraordinary job getting
Emdebian from 'some toolchains and good ideas' to 2 released
distribution variants and a pile of useful tools. It will take at
least 5 mere mortals to replace him.
I know it feels like Debian proper hasn't really made his job as easy
as it could be, but in fact I was struck at Debconf9 this time how
much the general vibe has changed since Debconf5. Wanting to
cross-build for arm is no longer some completely fringe activity.
Installing dev stuff for multiple architectures is now mainstream.
When proposing whacky things like cross-installing and corresponding
meta-data I get a serious hearing now, rather than being
entirely ignored.
There is still a really long way to go, but I'm reasonably happy that
things are headed in the right direction.
We (OK Neil), has shown that various things are actually possible (but
not maintainable in current form), which was always our objective when
the current scheme was hatched in 2005/2006.
I'll post more about the broader trends in a 'Debconf review' post
later.
> > My question, and one I'm sure has also occurred to others interested
> > in this project, is how do we move ahead during your absence.
There are two main threads:
1) using/maintaining/developing the current tools to update Crush
2) Working on mechanisms more closely tied into Debian proper to get
the things we need (shinkage, variant builds, cross-building,
cross-installing)
The former is largely 'just work' (lots of it), but the mechanisms are
understod and listed below. The latter is long-term and difficult, but
also affects many things beyond just embedded people (which means more
potential help but also more aspects to consider).
> 4. Struggle with the inherent weaknesses in apt-cross which lie in the
> horrible apt perl bindings - the most recent version of apt has (once
> again) broken these bindings and apt-cross needs a patch to continue
> operating. (Something to do with /etc/apt/preferences.d/). Hope that
> someone gets apt to understand multiarch so that this whole issue can
> be removed - you need a C++ expert for that role.
There was no apt guru at Debconf this year, but I talked to Ncommander
about this who fingered Michael Vogt as the man to hassle to get
apt-cross functionality into apt. Apt has to adapt anyway for
multiarch, so now is a really good time to push on this.
The transition from the existing way of doing things to the multiarch
way of doing things is going to be painful. Some of us are actually
using this stuff and will need both to work for a while...
> 5. Get the toolchains back into installable state - I can't upgrade my
> own armel boxes today but I don't have time to investigate why. Build
> scripts that ensure that this persistent problem is fixed for the long
> term and across all supported architectures.
This is a persistent problem, which I know puts off a lot of potential
users as they fall at this first hurdle. Removing the gcc-base
dependency would help a lot. We have done so in the past, but it tends
to come back. That's a nice simple, discreet job for someone to work on.
In the medium term the toolchains are going to move into Debian proper
(Agreed at Debconf) and cease to be our problem directly. At that
point the Debian/emdebian version skew should go away, and so will
installability issues (I very much hope).
> 11. Get Build-Depends split into debian/control and normal Debian?
> Possibly as well as Depends-Install (installed on build) and
> Depends-Runtime ?
There was some progress on this at Debconf, but I'm not sure we have a
consensus yet.
> Building a *static* chroot for another machine, only
> needs runtime stuff. Allows native cross-versions of packages, smaller
> installed images. No way to put a prefix in front of maintainer scripts
> for config files. Need a mangling frontend in dpkg before calling the
> script. Install time scripts vs runtime scripts. (A topic briefly
> discussed with Wookey, hopefully my notes aren't too brief for the idea
> to be reconstructed. I knew what I meant at the time.)
I discussed this some more with Phil Hands (from FAI) and we had some
useful ideas which I need to look at my notes about.
Scratchbox2 makes this problem disappear almost entirely and may
actually just be the best way to deal with it, rather than trying to
do it the hard way. There was much discussion between the various
teams that do variants on the process of making debian rootfs's (D-I,
FAI, debootstrap, cdebootstrap, multistrap, live CD people, LTSP,
etc). Trying to work out if some kind of 'libdebootstrap' that all
these tools could use was actually a good idea is a really good thing
to do (but a very long-term job). The current 14 tools all dealing
with the same issues is probably a big waste of people's time
maintaining them all.
> 15. Get CMake build systems cross-building properly.
I've got this working. I have along (but not yet sent) mail to go to
this list (and the CMAKE list) about how to make it less crufty. Where
this support should live, if dpkg-cross is to disppear remains an open
issue.
> 25. uClibc support
Decisions were made on this at Debconf. It will be a new arch, not
just an alternate libc package. This implies work in various places -
not least in toolchains.
> 26. Finalise the cache value support in dpkg-cross and add to it if
> necessary. Consider deploying the cache values into the Debian package
> such that the files can be created at build time on a
> per-package-per-architecture basis.
The dpkg maintainers would like this to disappear completely.
Personally I don't see how that's going to work. Someone needs to test
whether it can be moved out of dpkg-cross or not. And if not what we
propose to do. This is a fairly simple, discreet problem, that needs
someone to find a consensus and implement it.
> 27. Keep an eye on multiarch developments and feed into the process to
> ensure Debian gets a usable cross-build environment based on multiarch.
> Get dpkg-cross merged into dpkg as soon as multiarch is supportable.
We did a pile of this of Debconf and discussions were very positive.
There remains some questins on the overall implications of multiarch
and how the archive is going to deal with cross-dependencies. We
believe the spec is valid for our purposes, and we need to try using
it the moment dpkg supports it.
> 28. Whatever else I've forgotten.
>
> Is that enough for now?
I think that'll keep us entertained for a while. :-)
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
Reply to: