[Aboriginal] Is moving control-images to their own repository a good idea?

[Rob Landley]

On 07/03/2011 02:01 PM, prasanna balan wrote:
> The idea of seperation is nice, both technically and logically. Two
> different projects with different ideas mustn't be together....
> As for the COMPLETE dependency on aboriginal, it can be worked by
> assuming aboroginal scripts folder in the root directory
> and writing control images scripts in accordance...

There's two layers of dependency: creating the control images, and
running the resulting control images on a target system.

Building a "blah.hdc" image involves calling download_functions.sh
(which calls sha1file, dienow, is_in_list, announce, and dotprogress out
of utility_functions.sh), and expects to run in an environment like
host-tools.sh sets up (things like "which" and "mksquashfs" which may
not be there on all hosts).

That said, download_functions.sh and utility_functions.sh are fairly
mature these days, and I split 'em out so they could be used elsewhere.
 I'm probably ok snapshotting those and copying them into the
control-images tree.  (And if they diverge, I can either keep them in
sync by hand or not particularly care.)

When I'm building the control images, I can either install mksquashfs on
my host or run them under root-filesystem-i686.  This isn't realy
building anything significant, it's just downloading, extracting,
patching, and repackaging source code.  Copy stuff into known
directories and mksquashfs the result.  Cross compiling can fail in a
zillion different ways and do so subtly, this something like three
interesting prerequisites and isn't going to be subtle if it fails.

The other set of dependencies is _running_ control images.  In theory
you can mount it on /mnt and run /mnt/init under just about any root
filesystem.  As root.  Assuming you've got build tools, and if you don't
mind it installing all sorts of crud over your host system.

Part of what these things do is document the prerequisites and setup
steps for the Fedora build and such.  "How do you turn a minimal
environment into XXX".  However, we only test extending an Aboriginal
Linux root filesystem, a _known_ minimal starting environment.  There
aren't any EXPLICIT dependencies on it (except setup-chroot, but most
other root filesystems won't be read only, and again I may just copy
that into the control image).  There's some idiosyncratic directory
layout in there and such you won't find elsewhere.  Plus, I'm not
interested in doing the defensive programming of trying to make them
either work or fail gracefully in every possible starting environment: I
want to keep them simple.  That means making some assumptions about the
environment.  Assuming the environment is minimal and not crazy is a
pretty defensible thing to expect. :)

In some ways we just expect a busybox+uClibc environment with a
toolchain, and then replace everything we want to by installing over it.
 If you get a busybox+uClibc environment some other way, it should work
assuming everything's current versions.  If you try to run a control
image under something like Red Hat 9, or Yellow Dog Linux, or an ancient
SuSE install using a 2.4 kernel... well, maybe it'll work.  I'm not
going to stop you from doing it.

That said, lots of packages out there expect bash or perl.  There's only
one perl implementation, doesn't mean that your other thing is part of
the giant hairball that is perl, just because it uses it.  Depending on
aboriginal linux as a prerequisite is not the same as being a part of
aboriginal linux.

Rob