Re: [sprint] openembedded / dpkg-cross-buildpackage hybrid
+++ Neil Williams [2010-11-23 08:09 +0000]:
> On Mon, 22 Nov 2010 20:04:32 +0000
> Luke Kenneth Casson Leighton <firstname.lastname@example.org> wrote:
> > * debian does NOT have an automated "cross-compile-from-scratch"
> > system to create bootstrap images. openembedded does.
> And that's a good thing. Debian doesn't want that process because
> Debian wants to have the intermediary binary blobs because that is how
> Debian works.
Nevertheless, it would be genuinely useful to be able to automate the
process of building a new flavour or new architecture. This is
currently very hard work in Debian, and we could make the situation an
awful lot better. Whilst whole new arches are relatively rare that
doesn't mean we have to keep bootstraping them unecessarily difficult.
And flavoured rebuilds could be quite common - they would be used more
if they were easier to do. ARM is an architecture that particularly
highlights the utility of being able to build for different ISAs and
HWCAPs. In both these cases you can't use the existing
(arch-dependent) packages to build against because you don't have any.
Clearly we don't want to lose the binary debs that the builds output
but we do want to automate the dep-loop breaking, build ordering,
have multi-stage builds for packages that need to self-bootstrap, and
make packages cross-build properly (cross-dependency metadata,
getting paths right). Quite a lot of this is getting done as a result
of thing Linaro finds useful (some of it by me).
You _could_ do this using bitbake, as luke suggests, and better
support for debian package building in that environment would be
interesting. It might even be useful. I have no idea how well it would
actually work in practice, but it's not how I'm approaching the
problem (although I have considered exactly what luke is talking about
as an interesting idea).
> It is the entire point.
> > the latter item _is_ a serious problem, for multi-arch and weird
> > hardware capability combinations not yet imagined.
> It isn't a problem, it's not something to "solve". The blobs are a GOOD
> thing and if that's an issue, use OE.
You are focussing only the output of images vs blobs. I quite agree
that producing blobs is good, and making images from those is easy.
That doesn't mean that the other aspects of the problem which OE does
currently deal with much better than Debian do not need solving somehow.
> > ok - enough! thoughts anyone?
It's an interesting idea. Marcin has pointed out some of the issues
with this approach. I think there are more rigorous (aka more
'Debian-y') ways to deal with this problem, but if you wanted to try
doing some work on the 'using bitbake' scheme I'd be interested to see
how that works.
My approach is a combination of the parts detailed in these pages:
Feedback on that lot is welcome. Things that remain ill-defined are
how to manage flavours, HWCAPS and partial archives, although none of
these particularly matter for the essential cross-building and
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM