Merging Live and Install CDs

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Brian Sutherland wrote:
> On Fri, Feb 11, 2005 at 11:25:11PM +0530, Sridhar Ratna wrote:
> 
>>Why not have single CD that does boot lively and can be installed to
>>hard disk, instead of having two?
> 
> 
> If it could be done, I think it would be done.
> 
> A LiveCD contains the packages as if they were installed on a hard disk
> and a Install cd contains uninstalled packages. There is just not enough
> space on a cd for both.
> 

Perhaps reworking of the install process-- specifically, reworking apt
slightly-- would lead to an answer.

Currently, debs are package files containing everything you need.
However, in certain cases such as a live-install from CD, 'everything
you need' may consist of "a few bits of information" plus "a few files
laying around elsewhere."  Extending the .deb format to be able to
supply pseudo-packaging for linked media (i.e. .debs on a livecd are
linked to the livecd) would be possible.

The new pseudo-debs would be incompatible with older APT; but new normal
debs would be compatible with older APT, and older debs would be
compatible with newer APT.  Thus, the compatibility design issue is moot.

Whatever security issues are handled at a lower abstraction layer; the
.deb format itself handles signature regardless of if it's a normal deb
or some kind of experimental type.  Security issues are moot in our scope.

This leaves design and implementation issues.  Thus, how should this be
done, and where is the manpower coming from?  I won't answer these for you.

For the design though, I'll offer some insight.  The below information
is what we can assume:

 - Pseudo-debs are packed on a LiveCD or other media with the real debs
installed
 - The associated media is always accessable from the point of view of
the pseudo-deb
 - The associated media is read-only
 - Some contents of the debs will not survive on the media, and must be
stored in the pseudo-debs

So we'll tackle this simply:

 - Pseudo-debs can be generated by testing a real deb against a path and
checking for install files from the deb
 - Data found to be present and identical to the deb's contents is
discarded from the deb
  - This normally includes programs, libraries, and directories which
only hold data that wasn't changed (i.e. /usr/bin would be discarded
from a deb most likely)
  - This may or may not include configuration files
 - The pseudo-deb stores information to locate all data for the files
discarded from the pseudo-deb on the associated media, as well as any
hash sums to check the integrity
 - Remaining data is not derivable from the target associated media, and
is thus stored in the pseudo-deb as literal data
 - Other relavent information, such as conflicts and dependencies, is
stored in the pseudo-deb

In this way, pseudo-debs would only hold data not derivable from the
LiveCD.  This is likely to be mainly configuration files and dependency
information, and will probably compress to a few kilobytes each.  If
there are 1000 pseudo-debs of 20k each, 20M more are needed.  There are
912 packages on the Hoary Array 4 i386 Install CD; so 1M per K per deb
is a good estimate (it's more like 1M/1.11K).

I think the LiveCDs manage enough to spare a good 200 megs of space.
The Hoary Array 4 i386 LiveCD is 497MiB; Knoppix is 700MiB.  I believe
the goal should be about 50MiB total for pseudo-debs.

Now you only have 1 problem left:  Where to get manpower to implement
the idea.


> However, on a DVD ...
> 

- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCDVILhDd4aOud5P8RApuSAKCAf02KhYZhl7MvWmqJVbgu+n404gCdEeHn
Mhp3XY7et9EgFWLj9qwAuDU=
=m++o
-----END PGP SIGNATURE-----