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

[Rob Landley]

I've been thinking of moving sources/control-images to its own project
for a while now, and am poking at it this morning.

I downloaded the Linux From Scratch 6.8 tarball and started triaging
what I need to upgrade in lfs-bootstrap, and this brings up the whole
"should I do extensive changes in sources/control-images or should I
bite the bullet and move that directory to its own repository?"

I'm indecisive about this because control image building has some
dependencies on Aboriginal Linux.  Then again, having another project as
a build prerequisite isn't exactly unprecedented, is it?

Mark used to do Gentoo From Scratch as an overlay, which was never quite
clean (and way too easy for me to break), but now I've done proper
"mount /dev/hdc on /mnt and run /mnt/init" control image infrastructure
allowing it to be cleanly separated, more or less.  So at what point do
I bite the bullet and cleanly separate it?

Currently, building a control image uses the download/extract/patch
infrastructure from Aboriginal Linux, but I broke that stuff out into
sources/download-functions.sh so that's easier to copy over.  Might have
to keep 'em in sync, but it's at least reasonably contained now.  The
control images based on bootstrap-skeleton depend on /sbin/setup-chroot
from the Aboriginal Linux system images, but only if the root filesystem
is read only.

The _design_ is a bit dependent: the idea behind the "bootstrap" type
images themselves is to add stuff to a minimal environment until you
reach a target state, such as "gentoo" or "fedora" or "debian".  The
design here implies you start from a known minimal state, I.E. an
Aboriginal Linux system image or really, really similar.  For example:

http://landley.net/hg/aboriginal/file/1406/sources/control-images/lfs-bootstrap/mnt/build/setup.nosrc

Is more or less a series of steps from early Linux From Scratch, but
it's specifically as applied to the Aboriginal Linux system image
starting point.

Then again, look at that URL.  All those directories mean something, but
wow that's a long path...

On the Aboriginal Linux side we have the basic automated build
infrastructure which is reasonably clean (mount /dev/hdc on /mnt and run
/mnt/init, but be rigorously agnostic about what happens from there).
And we have some convenience functions (more/build-control-images.sh)
and hooks (buildall.sh runs build-control-images.sh).  Easy enough to
clean up.

The other hiccup is uploading the result (currently through the busybox
ftp server launched by the wrapper).  I've been pondering adding diod (a
v9fs server, more portable than trying to get virtfs to work on all the
targets, and not the crawling horror NFS is at the design level) and
just having an output directory the build copies stuff to.

The reason I haven't done this is that diod (like all the NFS servers)
exports a path using the name of the directory on the host.  If it's
under an arbitrary user home directory, it could be really long and have
spaces and such in it.  Haven't wanted to deal with that...

Anyway, that's the todo item du jour.  I should go poke the diod guy and
see if I can get alias support...

Rob