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. http://www.emdebian.org/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. Precisely. > 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. Correct. > ... 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 please.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpYnu1vxNvUj.pgp
Description: PGP signature