[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Very newbe help/pointers required about building a distribution from scratch

On Wed, 10 Mar 2010 21:08:30 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

(When replying, please shorten the CC list, preferably only to the
debian-embedded list.)

> >>  a bit like openembedded.

It's much easier to not do things like OE and to actually build
incrementally, putting dependencies into a local repository to make
them available as build-dependencies of the subsequent packages. That's
how Emdebian did it for Emdebian Crush 1.0.

> >>  ... but there's absolutely nothing that can be found, like that: it
> >> seems more that buildd is designed to be a half-way house, which is
> >> kinda useless for this sort of task, creating entire specialised
> >> rebuilds (a la gentoo) for specific architectures.

Debian is a binary distribution, it's designed to be built
incrementally and to use dependencies as binaries. Where others use a
staging area, Debian uses a repository which can be local.

emdebian-tools has scripts to do this but it's complicated and
cross-building Debian currently is hard.

> >>  yes, basically, i want to rebuild an entire suite of debian packages
> >> for the arm cortex A8 processor (the S5PC100).

armel? Use Emdebian Grip.


Why rebuild? What changes are you making to the packages? (Answers to
questions like this should go to the debian-embedded@lists.debian.org
mailing list, not debian-devel.)

(IMHO - and possibly a lot of other DD's - the benefits of building
packages for a specific machine ala gentoo with no other changes is
often heavily over-rated.)

> > A number of packages have circular dependancies. 

There is some work going on to fix those (nod to Holger and piuparts)
but finding a path through the dependencies is VERY VERY hard. The only
sane way is to start with the toolchain packages, work up gradually,
make mistakes, retrace your steps, go back and try another route then
make some progress until you reach the next impasse.

EVERY time you even think about changing any package during this
process, you have to recalculate the entire path from there on. It is
seriously painful.

> > These have to be
> > resolved manually by either temporarily using packages built elsewhere
> > or by manually building parts of a package to solve the dependancies.

>  or by using e.g. debian armel packages a la cross-debootstrap
> (rootstock under the dreaded ubuntu), that gets you into a position
> where each of those dependencies can be replaced one at a time.

>  ... where is all this documented?

It's not.

Documenting it means keeping it correct and that's just too much work.

>  has anyone actually done this

Yes. Me - I was cross-building the entire chain too. It took me the
best part of a year to get through 200 packages. i.e. SERIOUSLY
reconsider precisely how many packages you want to rebuild and how many
NEED to be rebuilt.

Unless you are making changes to the packages - indeed, unless you're
making FUNCTIONAL changes to packages - do not rebuild.

Use Emdebian Grip which provides smaller versions of existing Debian
packages without binary changes. Please discuss this further on the
debian-embedded mailing list.

> - documented and automated e.g. how the
> debian-armel port was created, when previously there was only the
> debian-arm one?

Native ports start at the toolchain and work up, gradually, putting
aside packages that build-depend on stuff you haven't built yet and
occasionally going back over the list. It takes time, lots of time.
>  because it really does make sense to have a way to do automated total
> recompiles for e.g. the cortex a8, and if debian won't "officially"
> add that as an architecture, at least having a well-documented and
> automated process by which a random person can just... set some
> machines compiling for a month, would be good.

*Precisely* what changes do you need for that "architecture" - is it
really a different architecture from armel? (Answers to debian-embedded


Neil Williams

Attachment: pgpZnxCwnUcKH.pgp
Description: PGP signature

Reply to: