Merging Live and Install CDs

[Matt Zimmerman]

On Fri, Feb 11, 2005 at 11:21:41PM -0500, John Richard Moser wrote:

> Matt Zimmerman wrote:
> > And of course some disadvantages as well:
> > 
> > - Somewhat increased memory requirements compared to the traditional
> >   installer (though very close to those of the installed system)
> 
> JigDebs wouldn't need more memory; but they'd need some extra space.
> I'd predict 20-50M, but I don't know really.  I'm basing this off the
> assumption that the average JigDeb is going to be 20-50k; and that
> there's about 1000 debs or less on an install CD.

The additional memory requirement is due to the live environment, which is
one of the primary advantages of a combined CD.  It has nothing to do with
the installation method (filesystem copy vs. package installation) which is
the crux of my proposal.

> > - Remastering is more complex
> 
> Remastering is only as complex with JigDebs as with a normal LiveCD,
> plus one extra step to fetch all used debs and strip them down to make
> JigDebs, transforming the CD from a LiveCD to a do-it-all.

This cannot be the case.  Any remastering process would need to maintain
synchronization between the live image and your proposed pseudopackages.
This would be much more complex than the existing remastering process.

> To recap, here's the JigDeb advantages:
> 
>  - Very simple

Your scheme is incredibly complex.  It would require massive changes to an
entire stack of tools in order to operate on a fundamentally different and
incompatible binary package format with wildly different assumptions.

>  - Minimal extra space usage

Extra space usage is a disadvantage.

>  - As suitable for LAN installations as using regular debs would be

Not nearly.  A network installation is based on retrieving binary packages
over the network, and your scheme would break that because the binary
packages are incomplete, requiring all of the file content to be retrieved
by some other means.

>  - Simple to remaster
>  - Simple to develope
>  - Simple to use -- single script could fetch all needed debs upon
> building a LiveCD and strip them down

I do not see how these could possibly be true.  The defining attribute of
this scheme would be additional complexity.

> And disadvantages:
> 
>  - Requires somebody to put forth the manpower to code this
>  - Likely to be slower, though not necessarily noticably slower
>  - Full debs cannot be regenerated signed

- Extremely complex
- Extremely fragile
- Fundamentally incompatible
- Would require an enormous development effort

Its advantage compared to the status quo is the possibility for a combined
installation, upgrade and live media which has a chance to fit on a single
CD.  However, in pursuit of this goal, it would sacrifice much of what is
good about the existing system, especially its robustness and versatility.

> >  For DVD, of course, we can have the best of both worlds, but CD will be
> >  with us for some time yet (especially as a download option).
> 
> The DVD should be avoided until two conditions are met:
>
>  - The average user has a 30mbit/s or higher connection; current
> connections are 5mbit/s and DVDs are about 4GiB.  We should shoot for
> the same download timeframe.
>  - DVD burners are an ubiquitous accessory

Judging by your conditions, I think you meant that "We should not stop
providing CDs until...".  However, we have no plans to stop supporting CDs.

We already produce installation DVD images in parallel with CD images, and a
combination live+install+upgrade DVD will be produced for Hoary (this is
simple to build with the current installer and live engine).

-- 
 - mdz