[issue523] grml-debootstrap: provide more options

[Michael Prokop]

New submission from Michael Prokop <mika at grml.org>:

Hi Mika:

What do you think of the following enhancement to grml-debootstrap? If you
ok with it, I'll start implementing *after* you release the new grml, for I
don't want to bother you when you are busy releasing new grml.

Add the following options to grml-debootstrap:

--base_tgz <tgz_file>

use the tgz file as the base system for grml-debootstrap, instead of
invoking debootstrap to build one. This allows people to utilize existing
base systems such as the grml daily-built one, or allow people to manually
fine tuning a base system before handling it over to grml-debootstrap.

Further note, without altering the grml-debootstrap configuration structure,
it is possible to use the following trick for grml-debootstrap to work on
different tgz files, i.e. different chroot base systems.

Before calling grml-debootstrap,

 mount -o bind /path/to/a/customized/debootstrap /etc/debootstrap

I.e., by bind mounting different configuration files, it is possible to
use grml-debootstrap to work on different base systems.

-b, --base_sys

Denote that the mountpoint specified by --mntpoint actually contains a
expanded base system as described above. Apart from eliminating the step of
expanding the tgz file, it enables building a modular live system which can
achieve slax's layered module architecture.

Further note on layered module architecture, instead of releasing different
sized live system differently, the slax derivatives' modular way is that
larger live systems are based on smaller ones. For example, here's a
sample module layout (ripped off from
http://forums.wolvix.org/index.php/topic,583.0.html):

* 01_kernel (Guess what's in here)

* 02_core (Core tools, like bash, and the basic GNU utilities)

* 03_ base_app (CLI applications like MC, Elvis, htop and Multimedia tools like 
ogg,
+normalize.)

* 04_base_lib (Basic libraries used by many apps. Mostly audio related.)

* 05_base_net (CLI network tools like mutt, elinks, bind, traceroute, etc.)

-- The grml small edition starts and ends here.

* 06_x11 (Xorg and fonts.)

* 07_common_desk (Xfce plus goodies, Fluxbox plus "goodies", icons, themes, 
wallpapers, etc.
+This one I'll break up a bit more, to separate Flux and Xfce.)

* 08_common_lib (All libs and requirements for the common applications. A lot 
of Gnome,
+graphics and multimedia libraries and bindings. Xfce has some deps here, guess 
I need to
+sort them out.)

* 09_common_app (All the GUI applications, network apps, graphics apps, office 
tools,
+multimedia apps, you name it. Guess this might be broken up a bit too)

-- grml media ends here.

* 10_more_lib (All the libraries and requirements for the apps in Hunter)

* 11_more_app (All additional apps for Hunter, not found in Cub plus large
things like Java and Samba. Perhaps I could make the two last separate
modules.)

-- grml large ends here.

This is just an example showing how Wolvix does module layout. The modular
approach has many advantages, For example, all files which belongs to
Xwindow are packed in xwindow module, KOffice related stuff is in koffice
module, etc. If you work with KOffice, you usually need only files from
KOffice and nothing else; and hence all files from that part of the
filesystem are separated from the rest of it, your CD drive has to seek only
in a 10 MB area, which might be fully cached by Linux kernel. This
significantly improves the speed. Another great advantage is that, I never
need to remaster slax any more, putting my extra stuff in is just as simple
as putting in several modules. My live-usb can always contains the latest
tools/docs of my own, without going through the remastering process.

I know grml is different but the spirit is the same. For example, we
can put forensic analysis, and network-penetration/intruder-detection tools
into different modules, and load them only when necessary.

The trick to build such layered modules in grml is to use Aufs to build a
virtual base system under mountpoint. For example, to build grml media on top
of grml small, use Aufs to combine the readonly grml small base system and
a writable empty directory as the mountpoint directory, then after using
grml-debootstrap to install/config packages for grml media, pack only
the changed files into the grml media module.

Please comment on my plannings. Mike, if it is feasible and make sense,
and after *everything* is agreed upon, I can start coding and send you
the patch set via email.

thanks

tong

----------
assignedto: mika
messages: 1472
nosy: mika
priority: feature
status: unread
title: grml-debootstrap: provide more options

_____________________________________
GRML issue tracker <bts at bts.grml.org>
<http://bts.grml.org/grml/issue523>
_____________________________________