From the SourceForge project summary:
Repairlix is a networked Linux distribution/bootable system intended to fit in 12MB of media - so small that an image can be burned onto a business-card-sized shaped CDROM, suitable for your wallet. It has a suite of utilities for doing system recovery.
Repairlix is now in the early stages of being useful. These early releases contain only enough logic to produce a bootable x86 ISO image, with perhaps some useful applications. No testing has been made to verify that any of this works on other architectures, although it should be highly portable to any system that supports the El Torito bootable spec. (Note: This only applies to the sources. I only have access to x86 architectures, so that will be the only platform for which I can build the ISO images I distribute. Therefore, these will be useless on other architectures.)
Repairlix has three design goals.
Small Media Size. It must be small enough to fit on any CD media you're likely to encounter. This is largely accomplished by compressing all the data on the CD, although obviously there will be some handpicked size optimizations (such as statically linking binaries where they require only rarely used libraries).
Modularity. Repairlix will not make use of package managers as such, but the architecture will support the ability to load different collections into the system at runtime. In addition to making it possible to build modified Repairlix's by including your own ramdisks (or modifying the existing sources), this makes it possible to run Repairlix in as much or as little memory as you want.
Transparency of Build Process. Repairlix will be as open as possible with regard to the tricks and techniques used to build the disk itself and populate it. Therefore, it will be useful as a teaching tool to others wishing to create their own distributions, or to modify Repairlix itself. This is accomplished by designing and building entirely with shell scripts and a Makefile, using only standard, unmodified tools. Also the NOTES file should be interesting to many people; in it I keep ruminations, problems, and solutions for problems I encounter while doing development. During the design phase, restricting development to only standard tools will make some things logistically harder, although it is also easier in the sense that I don't have to maintain much Repairlix-specific code.
These design goals contribute to the specification of the DropIns, described below. There is also more complete documentation available at the Repairlix home page.
A Repairlix DropIn is a package that is expanded at runtime, either when Repairlix boots up or by the action of a Repairlix user, to add functionality to the system. An example of a DropIn would be a package that expands to provide a booted Repairlix system with SSH.
You will find that the structure and design of the DropIn system is somewhat different from other package management systems. “Why are DropIns missing package management feature X?”You may also find yourself asking the question, “Why do we need another package management system?” In brief, DropIns aren't a package management system. DropIns are packages only in the sense that they are containers for logical units of software. There is no DropIn database, nor is there any way to uninstall DropIns. The reason is simple: You don't need to uninstall a DropIn.
Repairlix is a read-only filesystem at its core. All software run by a user of Repairlix is loaded into memory, and goes away as soon as the computer turns off. With no persistent storage, uninstalling Repairlix DropIns is a snap - you press and hold Ctrl-Alt-Delete. This doesn't mean you can't alter the filesystem that's loaded into memory; it simply means that those changes only last as long as your Repairlix session lasts. When you're done using Repairlix, any changes you made revert.
Also important is the fact that Repairlix must work in a diskless environment, running only from memory. Therefore Repairlix must take up as little memory as possible to work on as many systems as possible, and the DropIn system must not hinder that design goal.
Therefore,
Repairlix doesn't need a master list of all files on the system. These lists are kept primarily for uninstallation purposes. Furthermore, such a database would take up valuable memory.
Repairlix doesn't need the ability to build packages on the same system where the packages will be used. So, for example, there's no need for the equivalent of rpm --rebuild. You simply don't use Repairlix as a development environment when there's no persistent storage to keep your work around.
Repairlix doesn't need a complex configuration management system. Your configuration goes away when the computer gets rebooted, too. This means that DropIn designers must take on the burden of providing an intelligent default configuration, and making it easy to switch to some other configuration if need be.
DropIns don't need to be nice about overwriting other packages' files. Whoever gets installed last, wins. “Clobbering” doesn't exist because the entire system gets “clobbered” when it's turned off.
As above, there's no need for version control either. If you wanted version 2.1, install version 2.1 when the system loads, don't install version 2. If you do install version 2, and you later decide you want version 2.1, just overlay version 2. In any case, it's unlikely you'll find both versions on the same Repairlix CD unless they were mispackaged by somebody extending Repairlix; media space is precious too. Such a situation would only arise if you loaded Repairlix and then downloaded DropIns from a network.
DropIns are basically tarballs. They have a specific structure and naming convention which must be followed, but otherwise, they are exactly the same as any other tarball on your system, in order to maintain their transparency to the users and developers. No special tools are needed to get inside a DropIn.
Next, goal 1 demands that the tightest available compression be used; therefore, DropIns are always tarballs compressed with
grasshopper:~$ bzip2 -9 modulename.tar |
Finally, the name of the tarball is important. Other programs can easily verify the version of a DropIn because each file is named with the last 8 characters of its own md5 sum. An example of a properly-named DropIn is: rd-base#4dfa8c86.tar.bz2.
Note: This naming convention does not replace a secure method for distributing DropIns. Like any other software distribution, DropIns should be accompanied with an md5 file at their distribution sites so users can check after a complete download that the file they downloaded is the same file you distributed, and has not been sent by an interloper. The #md5sum naming convention is there to
provide a unique name for a DropIn in the absence of a proper version number. Distributors of RPMs frequently distribute code which appears to have the same version (for example “1.2.1-9”) but is actually different code, since each distribution adds its own tweaks to the package and may coincidentally produce a version system identical to another distribution's system. Even though both packages have the same base code, the “-9” each distribution adds to the end might mean different things. DropIns should still have a human-readable version accompanying the #md5sum in the filename, however.
verify file integrity when the file has been copied across a secure wire (for example, the wire connecting your hard drive to your CD burner). Burning an ISO to a CD is a notoriously error-prone process. If you get handed a Repairlix CD containing DropIns, you can quickly verify that each DropIn on the CD was burned correctly, and is still readable.
Repairlix expands its DropIns by doing:
grasshopper:~$ cd / grasshopper:~$ tar xvfj <dropin>.tar.bz2 |
Obviously, this means DropIns must be a packaged root (/) filesystem. This doesn't mean they need to contain their own libc or other components of a root filesystem! It just means that they should be able to overlay the root filesystem. This is very similar to another packaging system you might be familiar with, namely Slackware's tgz format.
Here's an (abbreviated) example, the rd-base DropIn.
./ ./bin/ ./bin/basename ./bin/bash ./bin/usleep ./bin/vi ./bin/zcat ./dev/ ./etc/ ./etc/bashrc ./etc/default/ ./etc/default/useradd ./etc/devfsd.conf ./etc/termcap ./home/ ./initrd/ ./lib/ ./lib/ld-linux.so.2 ./lib/libcom_err.so.2 ./lib/libcrypt.so.1 ./lib/libc.so.6 ./lib/libuuid.so.1 ./lib/modules/ ./lib/security/ ./lib/security/pam_cracklib.so ./lib/security/pam_deny.so ./lib/security/pam_permit.so ./lib/security/pam_pwdb.so ./lib/security/pam_warn.so ./linuxrc ./mnt/ ./mnt/cdrom/ ./mnt/floppy/ ./proc/ ./root/ ./root/.profile ./sbin/ ./sbin/depmod ./sbin/devfsd ./sbin/e2defrag ./sbin/e2fsck ./sbin/update ./tmp/ ./usr/ ./usr/bin/ ./usr/bin/[ ./usr/bin/ar ./usr/bin/basename ./usr/bin/bzip2 ./usr/bin/zip ./usr/lib/ ./usr/lib/cracklib_dict.hwm ./usr/lib/cracklib_dict.pwd ./usr/lib/cracklib_dict.pwi ./usr/lib/gconv/ ./usr/lib/gconv/gconv-modules ./usr/lib/gconv/ISO8859-1.so ./usr/lib/libcrack.so.2 ./usr/sbin/ ./usr/sbin/adduser ./usr/sbin/chroot ./usr/sbin/userdel ./usr/share/ ./usr/share/terminfo/ ./usr/share/terminfo/l/ ./usr/share/terminfo/l/linux ./usr/share/terminfo/v/ ./usr/share/terminfo/v/vt100 ./usr/share/terminfo/x/xterm ./var/ ./var/log/ ./var/run/ ./var/run/utmp |
As you can see, this DropIn creates empty directories, drops in binaries, drops in config files, and installs its own libraries. This is the model you will want to follow when you create your own DropIns. DropIns do not require sophisticated package management because every DropIn is responsible for its own dependencies. What you say !! Yes, every DropIn must install all the files it needs to run. You might fairly ask, “Doesn't this include libc and the other basic system files?”
The beauty of Repairlix is that you, as the developer, have a read-only filesystem as your target platform. That means you can always count on the same things being there if you gear your DropIn to a particular release of Repairlix! If the base Repairlix always has a certain version of libc, then your DropIn can depend on that being there, and does not need to include it.
To make the user experience a little nicer, the developer of a DropIn can include an optional configuration file which simply describes the DropIn. This file should have the same base filename as the DropIn with “.conf” appended. For example, a DropIn with the filename rd-base#4dfa8c86.tar.bz2 can include a configuration file named rd-base#4dfa8c86.conf.
The configuration file is plain text and has the following format:
# comments are allowed DROPIN_NAME="Sun StarOffice 5.2" DROPIN_DESC="This is a huge-ass office suite that has no business being on a repair disk." DROPIN_KEYWORD="staroffice" DROPIN_SIZE=25875612 |
As you can see, it is based on Bourne shell syntax. Any or all of these settings may be ommitted; default values will be supplied from the filename of the DropIn where appropriate.
A system for managing DropIns needs to do the following:
Provide an interface for the end-user to select a DropIn from the list using the module name. It may optionally display the DROPIN_DESC and DROPIN_SIZE. If the DROPIN_KEYWORD is used, it can be a shortcut to interface with a module. For example, a command-line DropIn manager might use the keyword to load the named module instead of requiring the user to remember the filename or type out the DROPIN_NAME string. The DMS should filter out of its list/not make available any package that has already been installed (see below).
Once the desired module is selected, the DMS should perform the appropriate untar action.
After the untar is complete, the DMS should create a file in /var/dropins containing the base filename of the module (e.g. rd-base#4dfa8c86). The file may be empty. This is the mechanism by which the DMS should discover which modules have been installed already, and filter its list.
A DropIn Management System does not need to provide a way to uninstall or erase DropIns after they are loaded. This can be done by rebooting the computer, since Repairlix is only loaded into memory.