Re: Very newbe help/pointers required about building a distribution from scratch
On 3/10/10, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> ... where is all this documented?
>
> has anyone actually done this - documented and automated e.g. how the
> debian-armel port was created, when previously there was only the
> debian-arm one?
There is a huge difference between recompiling packages of an existing
port with cpu-specific options and making a new port. I collected the
closest I got to useful advice for a new port at the bottom of
wiki.debian.org/ArmEabiPort
I did most of the armel port in 2006, and after being pushed to
cross-compile it by the emdebian crowd, it turned out this was
impossible because you have to compile most packages natively on the
same kind of Debian system.
The armel port was mostly bootstrapped by updating Maemo, which was
the first very early Debian armel system, if a bit rickety, aged and
incomplete (and sometimes plain messy), repairing it as best one could
then working up a spider's nest of dependencies between the 117
essential and required Debian packages, some of them circular, to get
closer and closer to a full self-building native true Debian system.
I got through 91 of them when in August my father was murdered in
front of me. Wookey slurped up the .deb's I had built and Buytenhek
completed the port in November/December - in his case by Debianizing
an ARM EABI OpenEmbedded base system, as far as I can tell.
I don't see how much of this could be automated, since every new port
depends on the existing work in the field.
However, in this case, cpu-optimization, the most effective way to
build cpu-optimized packages is to make a wrapper script called "gcc"
(and "cc" and "gcc-4.3" and "arm-linux-gnueabi-gcc") in some funny
directory, which you prefix to the PATH variable passed in
dpkg-buildpackage's environment. There is an example of this (for a
rare FPU) at the bottom of the section
http://martinwguy.co.uk/martin/crunch/#UsingIt
I don't know of any tools to recursively find the runtime package
dependency graph for you, but there are perl libraries that will
interrogate the package lists for you.
For your application you don't need to care about the order of the
package build, just an unordered list of the packages that you require
to populate your own local repository, then use that.
Even easier, just make a rootfs for your system from the standard
repository, then query the list of packages installed on that, rebuild
those into your own repository, then reinstall your system from that.
M
Reply to: