Will install CD and Live CD be merged in the future?

John Richard Moser nigelenki at comcast.net
Wed Mar 22 17:26:01 GMT 2006

Hash: SHA1

Matt Zimmerman wrote:
> On Wed, Mar 22, 2006 at 01:58:31AM -0500, John Richard Moser wrote:
>> There isn't enough space for both given the current implementation of
>> dpkg.  A few less-than-trivial hacks could make it happen, though.
> This is a lot harder than you think, and the benefits do not seem to justify
> the complexity.

It's less than trivial but I don't see how it's "A lot harder than I
think."  debian packages have a directory inside them called CONTROL
which contains package information.  dpkg would basically have to look
for CONTROL/livedebfiles or something to detect if it was a "live
package."  Without that, the package would look exactly like a regular
package; and of course, without that the package would need all files in
there as normal, so it would BE a regular package.

The logic is something like this:

dpkg --live-package-root /mnt/CLOOP -i foo.deb bar.deb

// Is this a live deb?
if (exists(CONTROL/livedebfiles)) {
 for each $i line in CONTROL/livedebfiles {
  file = get_filename($i); // get the filename and path
  sha = get_shasum($i); // get the stored sha1sum
  size = get_size($i); // get the stored file size
  if (!shaszmatch("$live_root/$file", sha, size)) {
   die("Cannot rebuild live package: $file changed!");
  // OK so we found the file, copy it into our unpacked tree
  // fix the package tree copy's permissions and ownership
  apply_perms_and_ownership_to_package_tree("$file", $i)
// continue on as normal

The assumption here is that dpkg unpacks a package and then processes
and installs it, meaning that somewhere in /tmp or /var/tmp exists an
untared set of preinstall and postinstall scripts, directories, files,
and CONTROL information.

All we are doing is injecting a check for CONTROL/livedebfiles after the
initial unpack, which collects files from elsewhere based on the
contents of CONTROL/livedebfiles.  If this file doesn't exist dpkg just
continues; if it does exist, dpkg fills in the rest of the files and
then continues.

This is not a magic switch; a set of 'live debs' is matched up with a
specific base file system to pull from.  The whole concept is just
redundancy elimination; I have two identical files, I'll delete one and
ln -s to the other as a replacement.

As for building the debs, as I said, automated.  All information in
CONTROL/livedebfiles can be gathered automatically with stat() and
sha1sum; files can be discarded from the deb by using 'rm' before
repacking it; and the deb can be signed automatically just like with the
original build scripts.

This is a lot simpler than you think.

Further thought though leads me to consider placing a line into
Packages.gz that dictates to apt-get that ../../../CASPER/root.squashfs
is needed for these debs; that way with the CD apt could go, "oh, I'll
mount this on 'mktemp /var/tmp/aptXXXXXX/liveroot' first and pass the
switch to dpkg, otherwise this will definitely not work."  Without this
line of course apt would act as normal.


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
                                     -- Evil alien overlord from Blasto
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the ubuntu-devel mailing list